summary refs log tree commit diff
path: root/pkgs/top-level/release-cross.nix
Commit message (Collapse)AuthorAge
* release-cross: use ghc844 for testsMatthew Bauer2018-11-03
| | | | | This GHC version has much better support for cross compilation. It should hopefully fix our mingw breakages from #42407. /cc @ericson2314
* release-corss.nix: fix ppc-embedded nameMatthew Bauer2018-11-02
| | | | s/powerpc-embedded/ppc-embedded
* Merge remote-tracking branch 'upstream/master' into release-lib-cleanupJohn Ericson2018-11-01
|\
| * systems/examples: add i686 & x86-64 embeddedMatthew Bauer2018-10-30
| | | | | | | | Fixes #28160
| * release-cross: add new targetsMatthew Bauer2018-10-29
| | | | | | | | | | | | | | | | | | adds: - arm-embedded - avr - aarch64-embedded - powerpc-embedded
| * release-cross: Cross compile from all 3 supported platformsJohn Ericson2018-10-23
| |
* | release-lib: Cache cross nixpkgs evals tooJohn Ericson2018-11-01
|/ | | | | This will help with release-cross.nix eval time. It also allowed me to share code between the cross and native helpers.
* release-lib: Filter supportedSystems with `meta.platforms`-style patternsJohn Ericson2018-03-19
| | | | | | | | | | | | | 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.
* prebuilt android tools: Init using SDKJohn Ericson2018-02-27
| | | | Expose as an option for the cross stdenv.
* release-cross: add nix and nixUnstableWill Dietz2018-02-22
| | | | | | | Essential software for every platform! :) 'nix' won't work for now, but add it anyway so later this tests "stable" nix 2.
* release-cross: minor cleanup, add aarch64-muslWill Dietz2018-02-22
|
* bootstrap-tools-cross, release-cross: add various musl entriesWill Dietz2018-02-13
|
* release-cross.nix: add entry for testing muslWill Dietz2018-02-13
|
* release-cross: Try building on Windows tooJohn Ericson2018-01-22
|
* release-cross: Add a test for Haskell on Raspberry Pi and "Android"John Ericson2018-01-21
| | | | | | Hello World with ghcHEAD. ghc822 to come after some patches. Android will be turned into real Android...later.
* release-lib: forAllSupportedSystems -> forTheseSystemsTuomas Tynkkynen2018-01-16
| | | | | I'm going to move forAllSystems from nixos/release.nix, and these functions sound too similar while doing different things.
* mingw-w64-pthreads: The C compiler is neededBojan Nikolic2018-01-02
| | | | | It was a copy and paste error from the headers derivation. Also test in release-cross.
* linux bootstrap tools: Use same derivation whether cross compiling or notJohn Ericson2018-01-02
|
* all-packages: Remove gccCrossStageFinal; any gcc will not workJohn Ericson2017-09-21
|
* lib: Consolidate platform configurations (used for crossSystem)John Ericson2017-05-29
| | | | This is good for maintenance and education.
* release-cross: Be less absurd in `ensureUnaffected` testsJohn Ericson2017-05-23
| | | | | We need to at least used a valid 4-part LLVM target "triple" and libc.
* gdb: Modernize and simplify derivationJohn Ericson2017-05-22
| | | | | | | - `isGNU` to `isHurd`, my sedding did not catch - Simplify cross compilation in general - Be more careful about python - no more `gdbCross` in all-packages
* glibc: Simplify derivation furtherJohn Ericson2017-05-20
| | | | | No native hashes should be changed with this commit default.nix's cross hash should also not be changed
* release-cross: Do a recursive union to make sure we don't loose testsJohn Ericson2017-05-18
|
* release-cross: Make tests more uniformJohn Ericson2017-05-17
| | | | | | 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.
* release-cross: Add arms test from Darwin for binutilsJohn Ericson2017-05-17
| | | | This does a decent job of testing everything in this PR up to here.
* lib platform parsing: Fix windows support to conform to LLVM, take 2John Ericson2017-05-17
| | | | | | | Second attempt at pull request #25275 This reverts commit b70924bd80918d153a5e2023afd7647ae7b24a12, reapplying 2282a5774cd80567644a44d31585bf965a55f9ec
* Revert "Merge pull request #25275 from Ericson2314/platform-normalize"Vladimír Čunát2017-05-06
| | | | | | | | 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.
* release-cross: Add final "-gnu" to fuloong tripleJohn Ericson2017-04-27
|
* lib platform parsing: Fix windowsJohn Ericson2017-04-27
| | | | | | | | 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
* release-cross: Fix more typos---this is embarrisingJohn Ericson2017-04-17
|
* release-cross: Fix typo preventing evaluationJohn Ericson2017-04-17
|
* lib: Fix system parsing, and use for doubles listsJohn Ericson2017-04-17
| | | | | | | 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
* lib: Collect system/platform related filesJohn Ericson2017-04-17
| | | | Previously, platforms was a random thing in top-level
* top-level: Less indirection for lib in release*.nixJohn Ericson2017-04-17
|
* release-cross: For fuloong, just use the predefined platformJohn Ericson2017-04-17
| | | | | 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.
* top-level: no more need to expose `splicedPackages`John Ericson2017-01-25
| | | | | This was just done temporarily on the last cross-overhauling PR for testing purposes.
* top-level: Introduce `buildPackages` for resolving build-time depsJohn Ericson2017-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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
* release-cross: Expose sub-jobs of linux cross stdenvJohn Ericson2017-01-15
|
* release-cross: Use `nativeDrv` rather than relying on defaultJohn Ericson2017-01-14
| | | | The default will soon change
* top-level: Add more options to release-cross.nix, normalize param commentsJohn Ericson2017-01-14
|
* release-cross: Test for unchanged native derivationsJohn Ericson2016-12-29
| | | | | | | 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.
* release-cross: Use the same genAttrs logic for `testOnCross` as `testOn`John Ericson2016-12-27
| | | | | Eventually we'll want to test cross-compiling *from* various platforms. For now, its good to be consistent.
* release-cross: Reformat to be far more legibleJohn Ericson2016-12-27
|
* release-cross.nix: Build the bootstrap tools for ARMTuomas Tynkkynen2016-07-20
|
* release-cross.nix: Remove bunch of packages that don't buildTuomas Tynkkynen2016-07-20
|
* release-cross.nix: Drop any platforms not having a single working buildTuomas Tynkkynen2016-07-20
|
* Disable system_tarball_pc and fix evalEelco Dolstra2015-07-22
| | | | | | It refers to a kernel version that no longer exists. (cherry picked from commit e4b9624ca89617005cb082e2a8301695759e1b19)
* Use mingw-w64 for 32bit Windows builds as well.aszlig2014-03-03
| | | | | | | | | 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>
* platforms.nix: Separate 32-bit and 64-bit PCsShea Levy2013-12-31
| | | | | | | With this, stdenv.platform.kernelArch can be used by the kernel builder for PC platforms too. Signed-off-by: Shea Levy <shea@shealevy.com>