Commit Graph

114 Commits

Author SHA1 Message Date
John Ericson
2227789392 lib: Collect system/platform related files
Previously, platforms was a random thing in top-level
2017-04-17 17:13:01 -04:00
John Ericson
b477851f34 top-level: Less indirection for lib in release*.nix 2017-04-17 17:13:01 -04:00
John Ericson
213d29f6b7 release-cross: For fuloong, just use the predefined platform
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.
2017-04-17 17:13:01 -04:00
John Ericson
c869fe022e top-level: no more need to expose splicedPackages
This was just done temporarily on the last cross-overhauling PR for
testing purposes.
2017-01-25 09:24:55 -05:00
John Ericson
bf17d6dacf top-level: Introduce buildPackages for resolving build-time deps
[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
2017-01-24 11:37:56 -05:00
John Ericson
a62ee8d45c release-cross: Expose sub-jobs of linux cross stdenv 2017-01-15 14:19:39 -05:00
John Ericson
fa0a12e35d release-cross: Use nativeDrv rather than relying on default
The default will soon change
2017-01-14 16:39:43 -05:00
John Ericson
427dbcb1d7 top-level: Add more options to release-cross.nix, normalize param comments 2017-01-14 14:25:56 -05:00
John Ericson
1d0e91831b release-cross: Test for unchanged native derivations
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.
2016-12-29 08:53:18 -08:00
John Ericson
db0dbd0b81 release-cross: Use the same genAttrs logic for testOnCross as testOn
Eventually we'll want to test cross-compiling *from* various platforms. For
now, its good to be consistent.
2016-12-27 15:41:07 -08:00
John Ericson
74753d01f8 release-cross: Reformat to be far more legible 2016-12-27 15:41:07 -08:00
Tuomas Tynkkynen
cd645c417a release-cross.nix: Build the bootstrap tools for ARM 2016-07-20 02:38:10 +03:00
Tuomas Tynkkynen
ee1a647bc2 release-cross.nix: Remove bunch of packages that don't build 2016-07-20 02:38:10 +03:00
Tuomas Tynkkynen
d0e25d815c release-cross.nix: Drop any platforms not having a single working build 2016-07-20 02:38:10 +03:00
Eelco Dolstra
4232f5d219 Disable system_tarball_pc and fix eval
It refers to a kernel version that no longer exists.

(cherry picked from commit e4b9624ca8)
2015-07-22 12:27:15 +02:00
aszlig
e64b342fa8
Use mingw-w64 for 32bit Windows builds as well.
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>
2014-03-03 22:38:48 +01:00
Shea Levy
58246936e4 platforms.nix: Separate 32-bit and 64-bit PCs
With this, stdenv.platform.kernelArch can be used by the kernel builder
for PC platforms too.

Signed-off-by: Shea Levy <shea@shealevy.com>
2013-12-31 21:34:44 -05:00
Domen Kozar
d31b8b2988 rpi: more packages to cross-compile 2013-05-26 12:54:26 +02:00
Domen Kozar
9229f669fc release-cross: add raspberrypi 2013-05-26 00:11:38 +02:00
Eelco Dolstra
c5f45036e6 release-lib.nix: Make the set of supported platforms an argument 2013-03-26 13:12:25 +01:00
Eelco Dolstra
2aa6f262cb Merge remote-tracking branch 'origin/master' into stdenv-updates 2013-02-15 13:36:34 +01:00
Shea Levy
af26af6fc7 Remove EOL'd Linux 3.6 2013-02-14 14:33:42 -05:00
Shea Levy
c23084906b Remove EOL'd Linux 3.3 2013-02-14 14:30:31 -05:00
Eelco Dolstra
6dba65b51f openoffice: Remove
It's superseded by LibreOffice and doesn't build anymore.
2013-01-29 12:43:53 +01:00
Eelco Dolstra
e2d505b24e More renames 2012-12-28 19:42:10 +01:00
Eelco Dolstra
5be0a9acd7 Rename hostDrv -> crossDrv, buildDrv -> nativeDrv
This is for consistency with terminology in stdenv (and the terms
"hostDrv" and "buildDrv" are not very intuitive, even if they're
consistent with GNU terminology).
2012-12-28 19:08:19 +01:00
Lluís Batlle i Rossell
0397d7c51e Removing the 2.6.39 kernel from release-cross; it wasn't in nixpkgs.
I add linux 3.6.
2012-11-29 10:27:34 +01:00
Lluís Batlle i Rossell
383b76df79 Fixing mingw-w64 builds. I can build simple C++ programs with gccCrossStageFinal.
I also add tests for hydra; let's see if it builds far.


svn path=/nixpkgs/trunk/; revision=34232
2012-05-24 22:07:23 +00:00
Lluís Batlle i Rossell
b71ca8c138 Updating the kernels to be cross-built by hydra. The list was quite outdated related to nixpkgs.
svn path=/nixpkgs/trunk/; revision=34224
2012-05-24 18:59:13 +00:00
Ludovic Courtès
2d7b05d332 release-cross: Build gnu.smbfs.hostDrv', not gnu.smbfs'.
svn path=/nixpkgs/trunk/; revision=32628
2012-02-27 17:50:44 +00:00
Ludovic Courtès
e86e5db579 release-cross: Add `gnu.smbfs'.
svn path=/nixpkgs/trunk/; revision=32500
2012-02-23 00:32:09 +00:00
Ludovic Courtès
c6210ec36d Samba: Fix compilation for GNU/Hurd; add to Hydra.
svn path=/nixpkgs/trunk/; revision=32498
2012-02-23 00:01:24 +00:00
Ludovic Courtès
81b3aecaec release-cross: Add OpenSSL for cross-GNU builds.
svn path=/nixpkgs/trunk/; revision=31349
2012-01-06 14:07:08 +00:00
Ludovic Courtès
05a447e462 Cross-build GCC 4.6 for GNU on Hydra.
svn path=/nixpkgs/trunk/; revision=30629
2011-11-29 22:54:22 +00:00
Ludovic Courtès
2c41dc1c06 release-cross: Remove `--with-system' hack for cross-building Nix.
svn path=/nixpkgs/trunk/; revision=30479
2011-11-19 14:33:37 +00:00
Ludovic Courtès
ab25775f1c release-cross: Adjust to `gnu.' renaming.
svn path=/nixpkgs/trunk/; revision=30477
2011-11-19 14:27:37 +00:00
Shea Levy
f469a69b43 Explicitly provide a nix system string when building nixUnstable.hostDrv for gnu
svn path=/nixpkgs/trunk/; revision=30459
2011-11-16 21:04:58 +00:00
Ludovic Courtès
54e4f2d5b5 Cross-build Guile 2.0 for GNU.
svn path=/nixpkgs/trunk/; revision=30419
2011-11-14 09:57:13 +00:00
Ludovic Courtès
aa6313051b Let Hydra cross-build more stuff for GNU.
svn path=/nixpkgs/trunk/; revision=27427
2011-06-12 21:53:56 +00:00
Ludovic Courtès
46d18d183d "coreutils_real" -> "coreutils".
svn path=/nixpkgs/trunk/; revision=25978
2011-02-15 13:15:55 +00:00
Ludovic Courtès
10f6eb70f1 Add more cross-MinGW and cross-GNU jobs.
svn path=/nixpkgs/trunk/; revision=25977
2011-02-15 13:14:33 +00:00
Lluís Batlle i Rossell
aa19343599 More cross packages for the nanonote
svn path=/nixpkgs/branches/stdenv-updates/; revision=24268
2010-10-13 20:47:24 +00:00
Lluís Batlle i Rossell
23b5b032de Trying to fix the uclibc cross biulds for linux 2.4
svn path=/nixpkgs/branches/stdenv-updates/; revision=23632
2010-09-03 19:25:05 +00:00
Lluís Batlle i Rossell
2971149bf4 Trying to get the uclbc sheevaplug cross build working.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23620
2010-09-03 14:59:04 +00:00
Lluís Batlle i Rossell
52f4540026 Trying to fix the mipsel linux-2.4 cross builds with uclibc (it lacked proper uclibc config)
svn path=/nixpkgs/branches/stdenv-updates/; revision=23606
2010-09-02 21:34:37 +00:00
Lluís Batlle i Rossell
b9e1bd9cd8 Who wants tightvnc? I'll set tigervnc into release-cross.nix instead of tightvnc.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23605
2010-09-02 20:40:33 +00:00
Lluís Batlle i Rossell
14a20b7179 Fixing the evaluation of cross built uclibc in the case of lacking extraConfig
svn path=/nixpkgs/branches/stdenv-updates/; revision=23602
2010-09-02 19:18:04 +00:00
Lluís Batlle i Rossell
6013c0cf8b Adding more platforms to crossbuild to (nanonote and the fuloong minipc)
svn path=/nixpkgs/branches/stdenv-updates/; revision=23601
2010-09-02 18:41:48 +00:00
Ludovic Courtès
454453a59d Attempt to cross-build Nix for GNU.
svn path=/nixpkgs/trunk/; revision=22373
2010-06-22 13:02:31 +00:00
Ludovic Courtès
343bbc2712 Have Hydra cross-build GNU Mach.
svn path=/nixpkgs/trunk/; revision=21987
2010-05-26 08:55:58 +00:00
Ludovic Courtès
a57d897d94 cross-GNU: Choose a different package set.
svn path=/nixpkgs/trunk/; revision=21941
2010-05-21 15:07:54 +00:00
Ludovic Courtès
23d4be19b4 Have Hydra cross-build the `basic' package set for GNU/Hurd.
svn path=/nixpkgs/trunk/; revision=21937
2010-05-21 13:47:07 +00:00
Ludovic Courtès
41cc998fd4 Have Hydra cross-build Coreutils.
svn path=/nixpkgs/trunk/; revision=21936
2010-05-21 13:47:00 +00:00
Ludovic Courtès
a7adcf1e3f Have Hydra build the cross Hurd.
svn path=/nixpkgs/trunk/; revision=21917
2010-05-20 11:54:43 +00:00
Ludovic Courtès
e4b15a9cee release-cross: Add `crossGNU' job.
svn path=/nixpkgs/trunk/; revision=21753
2010-05-12 15:46:55 +00:00
Lluís Batlle i Rossell
f0d7bf0541 Updating the hydra cross-build tests to build wxMSW and not wxGTK for mingw32
svn path=/nixpkgs/trunk/; revision=21635
2010-05-06 19:20:47 +00:00
Lluís Batlle i Rossell
c65304ff49 Telling hydra to build the cross-mingw32
svn path=/nixpkgs/trunk/; revision=21632
2010-05-06 18:47:35 +00:00
Lluís Batlle i Rossell
9b1d5353a9 Making the gcc cross-compiler a bit more flexible.
svn path=/nixpkgs/trunk/; revision=20614
2010-03-14 14:05:08 +00:00
Lluís Batlle i Rossell
648b17197f Adding linux 2.4 kernel headers for cross builds.
(I'm thinking of OpenWRT machines out there, mips, with linux 2.4)

svn path=/nixpkgs/trunk/; revision=20539
2010-03-10 20:44:48 +00:00
Lluís Batlle i Rossell
12e960f592 Adding dropbear, a small implementation of ssh2 client and server.
I made it statically build by default

I had to fix the zlib static cross-build, because the native stripping corrupted the target
static library. It is not the first time I see this.

I add drobear to the cross-built packages for hydra.


svn path=/nixpkgs/trunk/; revision=20518
2010-03-09 23:11:12 +00:00
Lluís Batlle i Rossell
33e549fa4f Adding a busybox option to build it statically.
Adding it to the cross builds.


svn path=/nixpkgs/trunk/; revision=20516
2010-03-09 22:44:45 +00:00
Lluís Batlle i Rossell
1522caa556 Enabling cross-builds with uclibc again (I had that too much abandoned).
Hydra now should even test it.


svn path=/nixpkgs/trunk/; revision=20500
2010-03-09 15:48:25 +00:00
Lluís Batlle i Rossell
da8c9de5a8 Updating the hydra builds for release-cross.nix
Now the attributes listed as Jobs will look even uglier - very long names, too much repeating.


svn path=/nixpkgs/trunk/; revision=20492
2010-03-09 14:14:30 +00:00
Rob Vermaas
b44af59afb separate cross builds in separate release expression, will add extra jobset
svn path=/nixpkgs/trunk/; revision=20484
2010-03-09 10:33:31 +00:00