set CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH based on NIX_CFLAGS_COMPILE and
NIX_LDFLAGS so that cmake's find_library like functions find all the libraries
gcc knows about thanks to the gcc wrapper
This is particular useful with myEnvFun which then also sets those CMAKE_* env
variables.`
Because setup.sh has to change this causes many rebuilds - thus it should be
included in a stdenv-update like branch
Also cmake builds in parallel perfectly fine
update cmake to latest minor number, I didn't change the patches,
just reapplied them manually recordin a new patch
Conflict in kerberos, which was updated both in master and in
stdenv-updates. Kept the stdenv-updates version, except pulled in the
enableParallelBuilding change from master.
Signed-off-by: Shea Levy <shea@shealevy.com>
Conflicts:
pkgs/development/libraries/kerberos/krb5.nix
Before this, the passthru attributes were only merged in with the
derivation attribute set, and there was no way to distinguish after the
fact which attributes were part of the derivation and which came from
passthru. Now passthru can be looked at separately as well.
Signed-off-by: Shea Levy <shea@shealevy.com>
Conflicts:
pkgs/development/libraries/libxslt/default.nix
Commit 1764ea2b0a introduced changes to libxslt
in an awkward way to avoid re-builds on Linux. This patch has been simplified
during this merge.
With multiple outputs, adding attributes to a derivation without
changing the {drv,out}Path is no longer as trivial as simply using the
`//' operator, as we usually want to add the attribute to _each_ output,
and even if we only care about one that one output can be reached via
multiple paths.
For stdenv.mkDerivation, we already had code in place to add passthru
and meta attributes to derivations. This commit simply factors part of
that code out into a lib function addPassthru, which takes a derivation
and an attribute set and appends the attribute set to each output of the
derivation.
Signed-off-by: Shea Levy <shea@shealevy.com>
Before, only the first output (and not even that when accessed through 'all' or its corresponding attribtue) had meta information and the relevant passthru attributes.
This doesn't change stdenv's hash and the tarball still builds, I'm pretty sure this is safe for master.
I'm not sure whether this was by intention, but so far postPatch hooks were
silently skipped whenever the patches list was empty. This change could possibly
change the build results of the following packages:
* gcc
* cmake (264)
* systemtap
* quemu-kvm
These packages all have in common that they have a postPatch hook and the
patches list can be empty when certain conditions are met.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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
export > $NIX_BUILD_TOP/env-vars
will fail if the name attribute contains a metacharacter
(e.g. "?"):
building path(s) `/nix/store/yk93gk3lc5bslcn5hklnzs0bdkp2r0an-icu-3.8-setBreakType-public.diff?rev=1.1'
/nix/store/gj8ac12mrwinbq7wzzhwfjjs3028a11x-stdenv-linux/setup: line 374: $NIX_BUILD_TOP/env-vars: ambiguous redirect
I guess this only happens if you happen to have an old temporary
build directory for the same derivation in /tmp.
This affects fetchurl in particular.
svn path=/nixpkgs/trunk/; revision=15915
* setup.sh: removed some obsolete features, specifically some that
were only used by the old build farm.
* addToSearchPath: removed some parameters that weren't used
anywhere.
svn path=/nixpkgs/branches/stdenv-updates/; revision=15136
instead of "gcc-4.3.3". This fixed the long-standing annoyance that
you can't distinguish the two in (say) nix-store -qR.
* On x86_64-linux, put $out/lib64 in the RPATH in addition to
$out/lib, because some packages (in particular GCC) put libraries in
$out/lib64 and ended up linking against the wrong library.
* Strip $out/lib64.
* Removed g77_42 because it's exactly the same as gfortran.
svn path=/nixpkgs/branches/stdenv-updates/; revision=14708
variables. This is so you don't have to write things like
preBuild=preBuild
preBuild() {
bla
}
svn path=/nixpkgs/branches/stdenv-updates/; revision=13941
paths. E.g. /usr/bin/perl is rewritten to /nix/store/<whatever Perl
is in $PATH>. Paths in the Nix store are left unchanged.
Contributed by Nicolas Pierron.
svn path=/nixpkgs/branches/stdenv-updates/; revision=12036
* 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
the fail() function unnecessary.
* Flag showBuildStats to print execution times on builder exit.
svn path=/nixpkgs/branches/stdenv-updates/; revision=11688
* Updated the kernel headers.
* ghc: setup hooks are now generated using substituteAll.
svn path=/nixpkgs/branches/stdenv-updates-merge/; revision=10838
stack traces impossible.
* When stripping all symbols on Darwin, don't use the "-s" flag
since it has a completely different meaning (it takes an argument
specifying a file containing a list of symbols).
svn path=/nixpkgs/branches/stdenv-updates-merge/; revision=10809
merge cleanly right away (kde-4, kernel stuff) so it should be
merged later. But the stdenv stuff is all there.
svn path=/nixpkgs/branches/stdenv-updates-merge/; revision=10793
in genericBuild. This also means that you can override a phase
function by redefining it, like
buildPhase() {
... do something ...
}
and you still get the log nesting stuff.
* GNUmakefile is also a valid makefile name.
* Evaluate the variables $preHook and $postHook to allow more stdenv
overrideability.
svn path=/nixpkgs/branches/stdenv-updates/; revision=10786
is skipped when there is no configure script). So you don't need to
set
buildPhase = "true";
for derivations that don't have any build action.
* Variable $makefile to allow the makefile to be specified.
svn path=/nixpkgs/branches/stdenv-updates/; revision=10784
The function for use in setup hooks. The syntax is very simple:
add_to_var varName needDir addDir prefix
If the directory $prefix$needDir exists, directory $prefix$addDir is added to
variable named varName (using PATH_DELIMITER as delimiter). If addDir is "", it
defaults to needDir (this is a most common case).
svn path=/nixpkgs/trunk/; revision=9496
Now you can write prefixKey="-prefix " and "-prefix ${out}" will be inserted in
configureFlags (instead of "--prefix ${out}").
svn path=/nixpkgs/trunk/; revision=9351
* Removed substitute, it's part of the generic builder now.
* stdenv-initial (Linux): use the real generic builder script. This
does require that sed is in the path of the builder of the initial
stdenv.
svn path=/nixpkgs/trunk/; revision=7498
fixupPhase strips binaries, runs patchelf, etc. This is so that
those things still happen when somebody overrides installPhase.
svn path=/nixpkgs/trunk/; revision=7494
often the same flags need to be passed to both `make' and `make
install'. Added a variable buildFlags for flags that should only be
passed to `make'.
svn path=/nixpkgs/trunk/; revision=7491
* If the environment variable buildCommand is set, then eval that
instead of doing the build phases. This is used by the runCommand
function in all-packages.nix to allow one-lines like
foo = runCommand "foo" {} "mkdir $out; echo foo > $out/foo";
svn path=/nixpkgs/trunk/; revision=7298
* Kernel: accept a list of kernel patches through the kernelPatches
argument. The names of the patches are added to the description
attribute (e.g., "The Linux kernel (with patches:
skas-2.6.18-v9-pre9)").
* Generic builder (forked in setup-new.sh): support patches that are
compressed using gzip or bzip2.
svn path=/nixpkgs/trunk/; revision=6913
This has a major advantage: you can write hooks directly in Nix
expressions. For instance, rather than write a builder like this:
source $stdenv/setup
postInstall=postInstall
postInstall() {
ln -sf gzip $out/bin/gunzip
ln -sf gzip $out/bin/zcat
}
genericBuild
(the gzip builder), you can just add this attribute to the
derivation:
postInstall = "ln -sf gzip $out/bin/gunzip; ln -sf gzip $out/bin/zcat";
and so a separate build script becomes unnecessary. This should
allow us to get rid of most builders in Nixpkgs.
* Allow configure and make arguments to contain whitespace.
Previously, you could say, for instance
configureFlags="CFLAGS=-O0"
but not
configureFlags="CFLAGS=-O0 -g"
since the `-g' would be interpreted as a separate argument to
configure. Now you can say
configureFlagsArray=("CFLAGS=-O0 -g")
or similarly
configureFlagsArray=("CFLAGS=-O0 -g" "LDFLAGS=-L/foo -L/bar")
which does the right thing. Idem for makeFlags, installFlags,
checkFlags and distFlags.
Unfortunately you can't pass arrays to Bash through the environment,
so you can't put the array above in a Nix expression, e.g.,
configureFlagsArray = ["CFLAGS=-O0 -g"];
since it would just be flattened to a since string. However, you
can use the inline hooks described above:
preConfigure = "configureFlagsArray=(\"CFLAGS=-O0 -g\")";
svn path=/nixpkgs/trunk/; revision=6863
set to the result, but don't use them in the actual derivation (so
they're not inputs). Useful to pass through extra attributes that
are not inputs, but should be made available to Nix expressions
using the derivation (e.g., in assertions).
svn path=/nixpkgs/trunk/; revision=6521
function to regenerate itself with a different setup script. This
is useful for experimenting with changes to the setup script in
specific packages without triggering a rebuild of everything.
* stdenv/generic/setup-latest.sh is a branch of setup.sh containing
pending changes that will be merged into setup.sh eventually.
* setup-latest.sh: don't use tar's "z" and "j" flags. Rather, call
gzip and bunzip2 directly.
svn path=/nixpkgs/trunk/; revision=6066
contains arbitrary information about a package, like this:
meta = {
homepage = "http://gcc.gnu.org/";
license = "GPL/LGPL";
description = "GNU Compiler Collection, 4.0.x";
};
The "meta" attribute is not passed to the actual derivation
operation, so it's not a dependency --- changes to "meta" attributes
don't trigger a recompilation.
Now we have to standardise some useful attributes ;-)
svn path=/nixpkgs/branches/usability/; revision=5024
all-packages. That is, an attribute like "bash" in all-packages.nix
should evaluate to the "bash" used to build stdenv, it shouldn't
build a new one.
Hm, this would be a lot cleaner if we had lazy_rec ;-)
svn path=/nixpkgs/branches/usability/; revision=4775
be passed to derivations that need to apply patches.
* GCC 3.4 is now the default compiler (old GCC renamed to `gcc-3.3').
* The temporary GCCs built during the stdenvLinux bootstrap are now
built without C++ support and without profiling.
* Remove fixincl in GCC 3.4 to prevent a retained dependency on the
previous GCC.
* Always set $prefix in setup.sh, even when there is no configure
script.
svn path=/nixpkgs/trunk/; revision=1444
On the downside, the build process of stdenvLinux builds gcc 9 times
(3 x 3 bootstrap stages). That's a bit excessive.
svn path=/nixpkgs/trunk/; revision=880
* Make builders unexecutable by removing the hash-bang line and
execute permission.
* Convert calls to `derivation' to `mkDerivation'.
* Remove `system' and `stdenv' attributes from calls to
`mkDerivation'. These transformations were all done automatically,
so it is quite possible I broke stuff.
* Put the `mkDerivation' function in stdenv/generic.
svn path=/nixpkgs/trunk/; revision=874
builders for typical Autoconf-style to be much shorten, e.g.,
. $stdenv/setup
genericBuild
The generic builder does lots of stuff automatically:
- Unpacks source archives specified by $src or $srcs (it knows about
gzip, bzip2, tar, zip, and unpacked source trees).
- Determines the source tree.
- Applies patches specified by $patches.
- Fixes libtool not to search for libraries in /lib etc.
- Runs `configure'.
- Runs `make'.
- Runs `make install'.
- Strips debug information from static libraries.
- Writes nested log information (in the format accepted by
`log2xml').
There are also lots of hooks and variables to customise the generic
builder. See `stdenv/generic/docs.txt'.
* Adapted the base packages (i.e., the ones used by stdenv) to use the
generic builder.
* We now use `curl' instead of `wget' to download files in `fetchurl'.
* Neither `curl' nor `wget' are part of stdenv. We shouldn't
encourage people to download stuff in builders (impure!).
* Updated some packages.
* `buildinputs' is now `buildInputs' (but the old name also works).
* `findInputs' in the setup script now prevents inputs from being
processed multiple times (which could happen, e.g., if an input was
a propagated input of several other inputs; this caused the size
variables like $PATH to blow up exponentially in the worst case).
* Patched GNU Make to write nested log information in the format
accepted by `log2xml'. Also, prior to writing the build command,
Make now writes a line `building X' to indicate what is being
built. This is unfortunately often obscured by the gigantic tool
invocations in many Makefiles. The actual build commands are marked
`unimportant' so that they don't clutter pages generated by
`log2html'.
svn path=/nixpkgs/trunk/; revision=845
checked whether absolute paths passed to gcc/ld refer to the store,
which is wrong: they can also refer to the build tree
(/tmp/nix-...).
* Less static composition in the construction of stdenv-nix-linux:
gcc-wrapper and generic are now passed in as arguments, rather then
referenced by relative path. This makes it easier to hack on a
specific stage of the bootstrap process (before, a change to, e.g.,
generic/setup.sh would cause all bootstrap stages to be redone).
svn path=/nixpkgs/trunk/; revision=833
