Age | Commit message (Collapse) | Author |
|
crossOverlays only apply to the packages being built, not the build
packages. It is useful when you don’t care what is used to build your
packages, just what is being built. The idea relies heavily on the
cross compiling infrastructure. Using this implies that we need to
create a cross stdenv.
|
|
cc-wrapper may wrap a cc-compiler, but it doesn't need one to build
itself. (c.f. expand-response-params is a separate derivation.) This
helps avoid cycles on the cross stuff, in addition to removing a
useless dependency edge.
I could have been super careful with overrides in the stdenv to avoid
the mass rebuild, but I don't think it's worth it.
|
|
Ensured hashes unchanged and eval succeeds in tarball job
|
|
See #27069 for a discussion of this
|
|
This is first step towards getting rid of gcc-wrapper-cross
|
|
Modify bootstrapping stdenvs to make sure `targetPlatform` also passed.
|
|
This is a saner default until stdenv's are removed altogether
|
|
The long term goal is a big replace:
{ inherit system platform; } => buildPlatform
crossSystem => hostPlatform
stdenv.cross => targetPlatform
And additionally making sure each is defined even when not cross compiling.
This commit refactors the bootstrapping code along that vision, but leaves
the old identifiers with their null semantics in place so packages can be
modernized incrementally.
|
|
Introduce new abstraction, `stdenv/booter.nix` for composing bootstraping
stages, and use it everywhere for consistency. See that file for more doc.
Stdenvs besides Linux and Darwin are completely refactored to utilize this.
Those two, due to their size and complexity, are minimally edited for
easier reviewing.
No hashes should be changed.
|
|
Document breaking change in 17.03 release notes
|
|
|
|
Close #13583.
|
|
Broken by changes introduced in d96893647de5c519c458c1254f043f2d67d9b29c
|
|
These will be more pleasant to use than the existing
(cc.cc.isClang or false)
nonsense we currently do.
|
|
also makes cc-wrapper compatible with clang in the darwin fork.
|
|
|
|
|
|
|
|
|
|
SDKROOT is standard. In particular, this fixes the cmake build on
Mac OS X 10.9.
|
|
The Carbon headers spew out zillions of multichar / deprecations warnings,
which isn't very helpful. So turn them off.
|
|
This variable sets the minimal Mac OS X version required for
running binaries produced by the Darwin toolchain. Since it
defaults to the version of the user's SDK, setting it explicitly
should make our builds more deterministic. It's now set to 10.6
because that's what hydra.nixos.org runs.
|
|
This required adding a new environment variable NIX_LDFLAGS_AFTER
that ensures that the -L.../usr/lib flag happens last.
|
|
Recent versions of Xcode don't install headers in /usr/include but
in a directory like
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include
So use that instead, falling back to /usr/include in case of an older
version of Xcode.
|
|
|
|
- Add solaris native ld support to GCC build wrapper
- Add solaris ld wrapper that fixes -L argument order
|
|
|
|
This allows various applications. It allows users to set global
optimisation flags, e.g.
stdenv.userHook = ''NIX_CFLAGS_COMPILE+=" -funroll-loops"'';
But the impetus is as an alternative to issue #229, allowing impure
stdenv setup for people who want to use distcc:
stdenv.userHook = "source /my/impure/setup-script.sh";
This is probably a bad idea, but at least now it's a bad idea in
people's configuration and not in Nixpkgs. :-)
|
|
svn path=/nixpkgs/trunk/; revision=33894
|
|
so that "nix-env -i stdenv" does the expected.
svn path=/nixpkgs/branches/stdenv-updates/; revision=31742
|
|
svn path=/nixpkgs/branches/stdenv-updates/; revision=31710
|
|
* Don't call xargs with the -r flag in the Darwin bootstrap.
svn path=/nixpkgs/branches/stdenv-updates/; revision=31703
|
|
in its interaction with the ‘dontStrip’ attribute.
svn path=/nixpkgs/branches/stdenv-updates/; revision=30848
|
|
svn path=/nixpkgs/branches/stdenv-updates/; revision=18878
|
|
svn path=/nixpkgs/trunk/; revision=18667
|
|
statement of the gcc-wrapper coreutils dependency on r17867.
I don't have i686-darwin to try this.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18490
|
|
svn path=/nixpkgs/trunk/; revision=15919
|
|
svn path=/nixpkgs/branches/stdenv-updates/; revision=13957
|
|
stdenv.
svn path=/nixpkgs/trunk/; revision=12147
|
|
* Some fetchurl-related refactoring. The `realCurl' attribute is
gone, `curl' is the real thing. To prevent an infinite recursion in
`fetchurl' (because it depends on curl and building curl needs
fetchurl), curl and its dependencies (openssl, zlib, perl) use
`fetchurlBoot', which is the fetchurl used by the previous bootstrap
phase (e.g. the statically linked version of curl for
stdenv-linux). So as a result you can use https:// urls almost
everywhere.
There's also some hackery to prevent a different curl from being
built in every stdenv-linux bootstrap phase (namely the
stdenv.fetchurl attribute which allows fetchurl to be overriden
everywhere).
svn path=/nixpkgs/trunk/; revision=11905
|
|
|
|
Glibc. This is useful when building GCC.
* gcc-wrapper: the dynamic linker has a different name on x86_64 and
powerpc.
* gcc-wrapper: "glibc" -> "libc", because someday we might support
different C libraries.
* gcc: don't do a multilib build (e.g., 32-bit support on x86_64),
don't need it.
* gcc: merge in support for static builds.
* gcc: various simplifications in the compiler/linker flags, hope they
work.
svn path=/nixpkgs/trunk/; revision=6823
|
|
svn path=/nixpkgs/trunk/; revision=6754
|
|
concatenation (+).
svn path=/nixpkgs/trunk/; revision=6080
|
|
svn path=/nixpkgs/trunk/; revision=5830
|
|
svn path=/nixpkgs/trunk/; revision=5715
|
|
svn path=/nixpkgs/trunk/; revision=5708
|
|
external binutils (i.e., Apple's cctools in /usr/bin).
svn path=/nixpkgs/trunk/; revision=5706
|
|
svn path=/nixpkgs/trunk/; revision=5702
|
|
svn path=/nixpkgs/trunk/; revision=5701
|