Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
https://hydra.nixos.org/build/65224506
Besides dontUpdateAutotoolsGnuConfigScripts, the 'arch' assignment was
wrong and resulted in "x64" (stdenv.isArm is not true on AArch64).
Issues addressed:
- xcode build failed with
... was built for newer OSX version (10.10) than being linked (10.5)
fixed by setting GYP mac deployment target to the nix value
- a gyp bug when SDKROOT is not set (and removed an orphaned gyp patch
- path to python in generated gyp-mac-tool
- noisy build due to static assert warnings, by silencing warnings
- use of system xcodebuild and libtool replaced by darwin.cctools
The build was originally failing due to a missing libtool. Trying to add
the buildInput "libtool" did not work out, since a few command line
arguments are not supported. I've applied the same workaround as for
"xcodebuild".
The second change is about the install step, where the path of
"libv8.dylib" was just slightly different.
Add the 'static' argument to the v8 package, which allows building the
package as a static library rather than a shared library. This allows
users to pass additional arguments to d8:
https://github.com/joestelmach/lint.vim/issues/10
Default v8 was fixed at 3.30.33, so running nix-build nixpkgs -A v8
would give us version 3.30.33, whereas nix-env -i v8 would install
version 4.5.107. Now, both commands build 4.5.107, and there is still an
option to install version 3.30.33
Similar to #14272, but fixes 4.5 build rather than generic.
- Ignores errors due to strict-overflow warnings
- Strips clang-only '-Wno-format-pedantic' flag out since this build
uses gcc
Ignore errors due to strict-overflow warnings; strip clang-only flag on
non-clang builds. Concerning the latter "fix", it's not entirely clear to me why
the -Wno-format-pedantic flag ends up being passed to gcc, the .gyp file appears
to already condition the inclusion of this flag on whether cc=clang.
(My OCD kicked in today...)
Remove repeated package names, capitalize first word, remove trailing
periods and move overlong descriptions to longDescription.
I also simplified some descriptions as well, when they were particularly
long or technical, often based on Arch Linux' package descriptions.
I've tried to stay away from generated expressions (and I think I
succeeded).
Some specifics worth mentioning:
* cron, has "Vixie Cron" in its description. The "Vixie" part is not
mentioned anywhere else. I kept it in a parenthesis at the end of the
description.
* ctags description started with "Exuberant Ctags ...", and the
"exuberant" part is not mentioned elsewhere. Kept it in a parenthesis
at the end of description.
* nix has the description "The Nix Deployment System". Since that
doesn't really say much what it is/does (especially after removing
the package name!), I changed that to "Powerful package manager that
makes package management reliable and reproducible" (borrowed from
nixos.org).
* Tons of "GNU Foo, Foo is a [the important bits]" descriptions
is changed to just [the important bits]. If the package name doesn't
contain GNU I don't think it's needed to say it in the description
either.
