ee58a5b30d6e60407b44fbb02ddade6c20fd8763 broke the plv8 build because it
upgraded the v8_6_x expression everywhere to the 6.9 branch, which came
with API changes. Notably, it seems plv8 only supports up-to v8 6.4.x at
this time.
This keeps a copy of the plv8_6_x expression inside the same directory
as the other v8 versions (so patches, etc are easy to apply), but it is
not exposed to the top-level of all-packages.nix.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
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.
