| Age | Commit message (Collapse) | Author |
|---|
|
Instead of intersecting system strings, we filter with the sort of
patterns used in `meta.platforms`.
Indicating this change `forTheseSystems` has been renamed to
`forMatchingSystems`, since the given list is now patterns to match, and
not the systems themselves. [Just as with `meta.platforms`, systems
strings are also supported for backwards compatibility.]
This is more flexible, and makes the `forMatchingSystems` and
packagePlatforms` cases more analogous.
|
|
Expose as an option for the cross stdenv.
|
|
Essential software for every platform! :)
'nix' won't work for now,
but add it anyway so later this tests "stable" nix 2.
|
|
|
|
|
|
|
|
|
|
Hello World with ghcHEAD. ghc822 to come after some patches.
Android will be turned into real Android...later.
|
|
I'm going to move forAllSystems from nixos/release.nix, and these
functions sound too similar while doing different things.
|
|
It was a copy and paste error from the headers derivation. Also test in
release-cross.
|
|
|
|
|
|
This is good for maintenance and education.
|
|
We need to at least used a valid 4-part LLVM target "triple" and
libc.
|
|
- `isGNU` to `isHurd`, my sedding did not catch
- Simplify cross compilation in general
- Be more careful about python
- no more `gdbCross` in all-packages
|
|
No native hashes should be changed with this commit
default.nix's cross hash should also not be changed
|
|
|
|
Fewer packages are only built on one platform. Eventually we should
have each package encode its own requirements on build host and target
(as we do for build already) and use that to test automatically.
|
|
This does a decent job of testing everything in this PR up to here.
|
|
Second attempt at pull request #25275
This reverts commit b70924bd80918d153a5e2023afd7647ae7b24a12,
reapplying 2282a5774cd80567644a44d31585bf965a55f9ec
|
|
This reverts commit 2282a5774cd80567644a44d31585bf965a55f9ec, reversing
changes made to 14adea91566019549f33392d4710d9babd0108d7.
The lib tests are bloking nixpkgs-unstable, and I don't like debugging
it soon enough.
|
|
|
|
There is no more `cygwin` OS, but instead a `cygnus` abi. "win32"
and "mingw32" parse as `windows`. Add a 3-part hack because autotools
breaks on explicit abi with windows-like (e.g. "i686-pc-windows-gnu").
Also change cross triples to conform
|
|
|
|
|
|
The old hard-coded lists are now used to test system parsing.
In the process, make an `assertTrue` in release lib for eval tests; also
use it in release-cross
|
|
Previously, platforms was a random thing in top-level
|
|
|
|
This is a semantic change, but probably a safe one. In any event, this is
very old hardware that probably no one uses anymore anyways.
|
|
This was just done temporarily on the last cross-overhauling PR for
testing purposes.
|
|
[N.B., this package also applies to the commits that follow it in the same
PR.]
In most cases, buildPackages = pkgs so things work just as before. For
cross compiling, however, buildPackages is resolved as the previous
bootstrapping stage. This allows us to avoid the mkDerivation hacks cross
compiling currently uses today.
To avoid a massive refactor, callPackage will splice together both package
sets. Again to avoid churn, it uses the old `nativeDrv` vs `crossDrv` to do
so. So now, whether cross compiling or not, packages with get a `nativeDrv`
and `crossDrv`---in the non-cross-compiling case they are simply the same
derivation. This is good because it reduces the divergence between the
cross and non-cross dataflow. See `pkgs/top-level/splice.nix` for a comment
along the lines of the preceding paragraph, and the code that does this
splicing.
Also, `forceNativeDrv` is replaced with `forceNativePackages`. The latter
resolves `pkgs` unless the host platform is different from the build
platform, in which case it resolves to `buildPackages`. Note that the
target platform is not important here---it will not prevent
`forcedNativePackages` from resolving to `pkgs`.
--------
Temporarily, we make preserve some dubious decisions in the name of preserving
hashes:
Most importantly, we don't distinguish between "host" and "target" in the
autoconf sense. This leads to the proliferation of *Cross derivations
currently used. What we ought to is resolve native deps of the cross "build
packages" (build = host != target) package set against the "vanilla
packages" (build = host = target) package set. Instead, "build packages"
uses itself, with (informally) target != build in all cases.
This is wrong because it violates the "sliding window" principle of
bootstrapping stages that shifting the platform triple of one stage to the
left coincides with the next stage's platform triple. Only because we don't
explicitly distinguish between "host" and "target" does it appear that the
"sliding window" principle is preserved--indeed it is over the reductionary
"platform double" of just "build" and "host/target".
Additionally, we build libc, libgcc, etc in the same stage as the compilers
themselves, which is wrong because they are used at runtime, not build
time. Fixing this is somewhat subtle, and the solution and problem will be
better explained in the commit that does fix it.
Commits after this will solve both these issues, at the expense of breaking
cross hashes. Native hashes won't be broken, thankfully.
--------
Did the temporary ugliness pan out? Of the packages that currently build in
`release-cross.nix`, the only ones that have their hash changed are
`*.gcc.crossDrv` and `bootstrapTools.*.coreutilsMinimal`. In both cases I
think it doesn't matter.
1. GCC when doing a `build = host = target = foreign` build (maximally
cross), still defines environment variables like `CPATH`[1] with
packages. This seems assuredly wrong because whether gcc dynamically
links those, or the programs built by gcc dynamically link those---I
have no idea which case is reality---they should be foreign. Therefore,
in all likelihood, I just made the gcc less broken.
2. Coreutils (ab)used the old cross-compiling infrastructure to depend on
a native version of itself. When coreutils was overwritten to be built
with fewer features, the native version it used would also be
overwritten because the binding was tight. Now it uses the much looser
`BuildPackages.coreutils` which is just fine as a richer build dep
doesn't cause any problems and avoids a rebuild.
So, in conclusion I'd say the conservatism payed off. Onward to actually
raking the muck in the next PR!
[1]: https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
|
|
|
|
The default will soon change
|
|
|
|
These derivations do not care about the target platform, and thus should
not be affected by cross-compiling. Currently, these tests *fail*, but they
will be fixed soon by a latter PR. The release-cross job doesn't block a
channel, so this should be no problem.
|
|
Eventually we'll want to test cross-compiling *from* various platforms. For
now, its good to be consistent.
|
|
|
|
|
|
|
|
|
|
It refers to a kernel version that no longer exists.
(cherry picked from commit e4b9624ca89617005cb082e2a8301695759e1b19)
|
|
Mingw(32) is rather poorly maintaned and has quite a lot of bugs. And
because our Windows cross builds were also poorly maintained and most of
the cross-tests were broken as well, I'm just taking this step and try
to switch to mingw-w64 for everything "cross Windows".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
With this, stdenv.platform.kernelArch can be used by the kernel builder
for PC platforms too.
Signed-off-by: Shea Levy <shea@shealevy.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's superseded by LibreOffice and doesn't build anymore.
|
