If set to false, mkDerivation will throw an exception if a package has
an unfree license. ‘release-lib.nix’ uses this to enforce that we
don't build unfree packages as part of the Nixpkgs channel. Since
this is set through Nixpkgs' ‘config’ argument, it's more finegrained
than $HYDRA_DISALLOW_UNFREE.
Conflicts:
pkgs/development/compilers/gcc/4.6/default.nix
pkgs/development/compilers/gcc/4.7/default.nix
The 4.7 had some weird parameters added in crossAttrs; I've removed
them, but I don't understand where they come from.
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).
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. :-)
If the environment variable HYDRA_DISALLOW_UNFREE is set to "1", then
evaluation of a package with license "unfree" will throw an error.
Thus such packages or any packages that depend on them will fail to
evaluate.
what the new nix thinks the fuloong is.
Anyone having the old nix should use a nixpkgs previous to this change to build
the new nix. And then, with the new nix, he can use any newer nixpkgs revision.
svn path=/nixpkgs/trunk/; revision=31751
bash's pattern replacement feature. "replace-literal" is an
uncommon command so it was a headache during the bootstrap.
svn path=/nixpkgs/branches/stdenv-updates/; revision=31681
some redundant builds (e.g., GMP was built three times).
* Updated GMP to 5.0.2.
* Updated PPL to 0.11.2.
* Remove ad hoc flags to build GCC's dependencies statically.
Instead, use the ‘makeStaticLibraries’ stdenv adapter.
* Build GMP with C++ support by default.
svn path=/nixpkgs/branches/stdenv-updates/; revision=30891
These markers follow the format of those of `nix-store --print-build-trace',
which allows extraction of, say, phase durations in a similar way.
svn path=/nixpkgs/branches/stdenv-updates/; revision=26115
If a build expressions has set "enableParallelBuilding = true", then the
generic builder may utilize more than one CPU core to build that particular
expression. This feature works out of the box for GNU Make. Expressions that
use other build drivers like Boost.Jam or SCons have to specify appropriate
flags such as "-j${NIX_BUILD_CORES}" themselves.
svn path=/nixpkgs/trunk/; revision=23042
Instead, use the generic package override mechanism to use packages
from earlier bootstrap phases.
* Don't rely on the existence of attributes such as
`stdenv.coreutils'.
svn path=/nixpkgs/trunk/; revision=22991
If a build expressions has set "enableParallelBuilding = true", then the
generic builder may utilize more than one CPU core to build that particular
expression. This feature works out of the box for GNU Make. Expressions that
use other build drivers like Boost.Jam or SCons have to specify appropriate
flags such as "-j${NIX_BUILD_CORES}" themselves.
svn path=/nixpkgs/branches/stdenv-updates/; revision=22399
"meta" and "passthru", and these attributes will be appended to the usual
mkDerivation attributes only if the package is cross built.
This allows putting some of the cross-building logic in the mkDerivation
nix parameters, and not only in the final builder script, as it was until now.
svn path=/nixpkgs/trunk/; revision=20272
renaming.
I think directory renaming breaks the usual merges... because it leaves the
'to be removed' directory in the working directory still. A manual 'rm' of the
'to be removed' directory fixed the commit.
svn merge ^/nixpkgs/trunk
svn path=/nixpkgs/branches/stdenv-updates/; revision=18661
inputs did not get in)
Updating the xorg builder script to support cross building (in fact, support
for propagating the required build inputs).
svn path=/nixpkgs/branches/stdenv-updates/; revision=18569
- Before this changes, cflags and ldflags for the native and the cross compiler
got mixed. Not all the gcc-wrapper/gcc-cross-wrapper variables are
independant now, but enough, I think.
- Fixed the generic stdenv expression, which did a big mess on buildInputs and
buildNativeInputs. Now it distinguishes when there is a stdenvCross or not.
Maybe we should have a single stdenv and forget about the stdenvCross
adapter - this could end in a stdenv a bit complex, but simpler than the
generic stdenv + adapter.
- Added basic support in pkgconfig for cross-builds: a single PKG_CONFIG_PATH
now works for both the cross and the native compilers, but I think this
should work well for most cases I can think of.
- I tried to fix the guile expression to cross-biuld; guile is built, but not
its manual, so the derivation still fails. Guile requires patching to
cross-build, as far as I understnad.
- Made the glibcCross build to be done through the usage of a
gcc-cross-wrapper over the gcc-cross-stage-static, instead of using it
directly.
- Trying to make physfs (a neverball dependency) cross build.
- Updated the gcc expression to support building a cross compiler without getting
derivation variables mixed with those of the stdenvCross.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18534
derivation, the "buildInputs" in every stdenv mkDerivation don't map now
directly to the environment
variable "buildInputs" in the builder, but "buildNativeInputs". So, the inputs
build by the native compiler.
When cross compiling, they will map to the environment variable "buildInputs"
(yes, now the same name), which means does to be built with the cross compiler.
I think I improved the naming of variables a bit. There was a big mess,
specially in the stdenv adapter for cross building, and also in the default
builder script.
I also tried to add proper manager of propagatedInputBuilds, these being
propagated considering the host or build origin of that input build (so, at the
end, being those propagatedInputBuilds being propagated properly to the native
or the cross compiler.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18477
the cross compilation functionality.
- I renamed some expected stdenv.mkDerivation parameter attributes so we can
keep this branch properly updated from trunk. We agreed with Nicolas Pierron
doing a massive renaming, so all current buildInputs become hostInputs (input
as build for the host machine, in autotools terminology) , and
then buildInputs would mean "input as for the build machine".
By now, the specific "input as for the build machine" is specified through
buildNativeInputs. We should fix this in the merge to trunk.
- I made the generic stdenv understand the buildNativeInputs, otherwise if
we start changing nixpkgs expressions so they distinguish the current
buildInputs into buildInputs and buildNativeInputs, we could break even more
nixpkgs for other platforms.
- I changed the default result of mkDerivation so it becomes the derivation for
to be run in the build machine. This allows, without any special rewriting,
"fetchurl" derivations to be always results for the build machine to use
them.
- The change above implies that, for anyone wanting to cross-compile, has to
build the hostDrv of the wanted derivation. For example, after this commit,
the usual test of "nix-build -A bison.hostDrv arm.nix" works. I described
the contents of this arm.nix in r18398.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18471
I made the stdenvCross adapter simpler, according to Nicolas Pierron comments,
and I commented it a bit.
There are still jobs to do. At least:
- Plan for the general renaming from buildInputs to hostInputs
- We should not break merges from trunk.
- Make the generic stdenv understand about host/buildInputs, at least for
native builds, because it is used in the always-native building of
stdenvLinux. This should allow us to remove all duplications of "*NoCross" in
nixpkgs.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18449
This comes from:
svn diff ^/nixpkgs/trunk/@18255 ^/nixpkgs/branches/stdenv-updates/ > diff
patch -p0 < diff
and then adding into svn all files new from the patch.
trunk@18255 comes from the last time I updated stdenv-updates from trunk.
svn path=/nixpkgs/stdenv-updates2/; revision=18272
I thought I didn't change stdenv, but I did. This will go soon into the stdenv
branch then.
Reverse-merging r16467 through r16465.
svn path=/nixpkgs/trunk/; revision=16468
