with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
Because the configure script hasn't been update to work with Python 3.10
and never will. Spidermonkey 78 is EOL.
Traceback (most recent call last):
File "/build/firefox-78.15.0/obj/../js/src/../../configure.py", line 25, in <module>
from mozbuild.configure import (
File "/build/firefox-78.15.0/python/mozbuild/mozbuild/configure/__init__.py", line 33, in <module>
from mozbuild.util import (
File "/build/firefox-78.15.0/python/mozbuild/mozbuild/util.py", line 760, in <module>
class HierarchicalStringList(object):
File "/build/firefox-78.15.0/python/mozbuild/mozbuild/util.py", line 785, in HierarchicalStringList
class StringListAdaptor(collections.Sequence):
AttributeError: module 'collections' has no attribute 'Sequence'
Split the argument list into build and runtime dependencies and sort
everything alphabetically.
Unpin icu, it works with icu70, which is the latest version at this
time.
Remove yasm, it's not needed in firefox either.
Spidermonkey depends on rustc, so we have the best chance at only
having a single LLVM in the build closure if we use the same LLVM that
rustc depends on.
cc-rs is hardcoded to use the soft-float ABI for riscv64, while
the rest of the system is double-float. This is not just a missing
stub header file - You can't link object files using different
ABIs.
The configurePlatforms mkDerivation parameter needs to be an empty list
to avoid bogus defaults from breaking cross compilation.
Document the parameter to prevent it from being cleaned up.
The use of unspliced llvmPackages in configureFlags was causing an
eval failure when cross-compiling, but since later versions of
Firefox/Spidermonkey can correctly detect clang and libclang without
those arguments being specified, we can just backport that
patch (which applies cleanly), and not have to worry about it any
more.
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
