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
does not override NIX_CFLAGS_COMPILE anymore in the mkDerivation parameter
attributes. This way, apacheHttpd can be built properly with coverage
information.
An indication of this problem came from the nixos tests.subversion failure.
svn path=/nixpkgs/branches/stdenv-updates/; revision=24938
bootstrap-tools, because zlib was there and binutils were not having an
explicit buildInput for zlib. Due to that, we ended up with stdenv
(gcc-wrapper) depending on bootstrap-tools as runtime dependency.
svn path=/nixpkgs/branches/stdenv-updates/; revision=24790
newest I uploaded yesterday. These have gcc 4.5.1, that fulfills the glibc
2.12.1 requirement of having a compiler equal or greater to gcc 4.4 to build
proper x86 32-bit code (http://sourceware.org/bugzilla/show_bug.cgi?id=12123)
svn path=/nixpkgs/branches/stdenv-updates/; revision=24523
had a little svn mess in the working directory that ended up in a not working
stdenvLinux.
This time I even chose better names for the attributes, so they match better
the comments.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23428
I had done an attempt recently, unsuccesful, which ended in a recent revert.
This change works.
I even updated the comments in the file.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23425
What I did results in segfaults in built binaries.
svn merge -c -23370 ^/nixpkgs/branches/stdenv-updates
svn path=/nixpkgs/branches/stdenv-updates/; revision=23376
This should allow keeping the i686-linux boostrap-tools.
I updated some days ago the x86_64-linux bootstrap-tools, but that update is
not needed anymore. We can revert that boostrap-tools update if anyone wants.
Pro:
- new gcc building gcc and glibc.
Contra:
- maybe some old systems (patched red had kernels come to mind) break with that update?
svn path=/nixpkgs/branches/stdenv-updates/; revision=23370
Allowing 'curl' build without some dependencies, if it is told not to build
with them.
Updating the make-bootstrap-tools for the latest gcc/glibc, removing the
dependency on klibc, and updating unpack-boostrap-tools for the latest
boostrap-tools to work.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23305
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
* libpng updated to 1.4.0.
* For libjpegStatic, use a stdenv adapter to build a static library.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19605
I fixed conflicts regarding the renaming 'kernel' -> 'linux' in all-packages.
Also a small conflict in all-packages about making openssl overridable.
And I some linux 2.6.31-zen kernel files also marked in conflict.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19438
we can't build easily with them gcc-4.4 natively, because of a bug in the ld of the
previous bootstrap-tools.
I updated the unpack script to include the new gcc-4.4 libraries *ppl*.so in patchelfing.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18835
(dynamic libraries of ppl and cloogppl) into the package.
We need newer binutils in the bootstrap-tools for the armv5tel in order to
be able to build gcc 4.4 from them.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18747
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
this because 'ld' wants to know the path of every library involved in a dynamic
linking. I imagine that ld does not need that in native builds because it can
call the loader for it to resolve the library rpaths, but this is not the case
for cross-building.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18577
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
- Disabling guile test, because one fails. I commented on that in the source.
On cross builds:
- Adding stripping
- Updating the glibc-2.11 expression to match the parameters of glibc-2.9,
which I was updating more.
- Renaming from selfNativeBuildInput to selfBuildNativeInput, so this matches
better the pattern buildNativeInputs.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18550
- 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
on a derivation with a meta.license attribute which does not satisfy the
license predicate.
With this adapter you can abort any install which depends on software
which are not free by default. You can try it with MPlayer, because
MPlayer depends of win32codecs flagged as "unfree".
svn path=/nixpkgs/trunk/; revision=18530
its dependencies. To make it works, you need to change the default
stdenv as documented in the error message.
./maintainers/scripts/dep-licenses.sh <attribute name>
svn path=/nixpkgs/trunk/; revision=18508
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
true/false, which tells whether the derivation needs itself as
buildNativeInput.
For example, in order to build cross ncurses, we need the a native build
ncurses.
(As libtool does not work in stdenv, I have not tested this change, to check
whether finally ncurses cross-build)
svn path=/nixpkgs/branches/stdenv-updates/; revision=18489
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
needing to keep a new tree of expressions apart for the expressions to get
cross-compiled.
I changed the whole way of using cross compilation with nixpkgs, which before
was done through a simple adapter.
Now the adapter became complex, and I've tried to avoid the most obvious
recursivities. For example, the fetchurl expression should
never be cross-compiled, as the gmp, mpfr, and some others, like
some ncurses, perl, ... I made overrided copies of those necessary as
perlNoCross, ncursesNoCross, as stdenvNoCross, keeping in mind that
the stdenv (capable of cross compilation) is built upon stdenvNoCross using
an adapter.
So, to cross compile, instead of building using "nixpkgs/default.nix",
you should build with your
own "myarchiteture.nix", which should have contents like these, for example:
import /etc/nixos/nixpkgs/default.nix
{
crossSystem = {
config = "armv5tel-unknown-linux-gnueabi";
bigEndian = false;
arch = "arm";
float = "soft";
};
}
svn path=/nixpkgs/branches/stdenv-updates/; revision=18398
It still does not work, but I think I already get glibc cross compiled.
Next: gcc and g++, and set some setup script hooks on stdenvCross.
It took quite enough hours for this commit.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18351
My idea is to provide special stdenv expressions that will contain in the path
additional cross compilers. As most expressions for programs accept a stdenv parameter,
we could substitute this parameter with the special stdenv, which will have a
generic builder that attempts the usual "--target=..." and can additionally
have an env variable like "cross" with the target architecture set.
So, finally we could have additional expressions like this:
bashRealArm = makeOverridable (import ../shells/bash) {
inherit fetchurl bison;
stdenv = stdenvCross "armv5tel-unknown-linux-gnueabi";
};
Meanwhile it does not work - I still cannot get the cross-gcc to build.
I think it does not fill the previous expressions with a lot of noise, so I
think it may be a good path to follow.
I only touched some files of the current stdenv: gcc-4.3, kernel headers
2.6.28, glibc 2.9, ...
I tried to use the gcc-cross-wrapper, that may be very outdated. Maybe I will
update it, or update the gcc-wrapper expression to make it fit the cross tools,
but meanwhile I even cannot build gcc, so I have not tested the wrapper.
This new idea on cross compiling is not similar to that of the
nixpkgs/branches/cross-compilation, which mostly added bare new expressions for
anything to be cross compiled, if I understood it correctly.
I cared not to break anything of the usual stdenv in all this work.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18343
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
tree under $out into a separate stdenv adapter named keepBuildTree.
* makeModulesClosure: support building an initrd for a kernel that has
been compiled with coverage instrumentation.
svn path=/nixpkgs/trunk/; revision=16916
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
LD_LIBRARY_PATH since it breaks /bin/sh on non-NixOS platforms (and
reverted the previous "fix" in r15470).
svn path=/nixpkgs/branches/stdenv-updates/; revision=16029
* Use patchelf 0.5 and use the --force-rpath flag. This removes the
need for setting LD_LIBRARY_PATH and so should fix bootstrapping
Nixpkgs on non-NixOS platforms.
svn path=/nixpkgs/trunk/; revision=16022
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
* Updated stdenv-linux:
- The bootstrap tools are no longer statically linked (except for
binaries in the Nixpkgs tree used to download and unpack the
bootstrap tools).
- x86_64 uses the same static binaries as i686. This makes the
Nixpkgs tree a bit smaller.
- Use the Linux 2.6.28 headers.
svn path=/nixpkgs/branches/stdenv-updates/; revision=13946
variables. This is so you don't have to write things like
preBuild=preBuild
preBuild() {
bla
}
svn path=/nixpkgs/branches/stdenv-updates/; revision=13941
setting the NIX_INDENT_MAKE variable; disabled by default) so we
don't need a separate gnumakeNix package.
svn path=/nixpkgs/branches/stdenv-updates/; revision=13807
Instead of using a mishmash of statically linked and dietlibc
programs (which often have problems on various platforms), we just
use normal, dynamically linked binaries, and use some patchelf magic
to rewrite them so that they can find Glibc. Also include G++ and
Perl, since there are some builds in the bootstrap that need them.
svn path=/nixpkgs/branches/stdenv-updates/; revision=13788
* In stripDirs: use xargs -r, otherwise when there is nothing to
strip, strip prints its help text. Harmless but annoying.
svn path=/nixpkgs/trunk/; revision=13492
bootstrap wasn't recycled in the final allPackages, causing an
additional glibc to be built for packages that explicitly depend on
glibc.
svn path=/nixpkgs/trunk/; revision=12200
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
* GCC 4.2: restore the ability to build a statically linked compiler,
needed for the Nixpkgs bootstrap.
* GCC 4.2: use symlinks instead of hard links in $out/bin
(NIXPKGS-62).
svn path=/nixpkgs/branches/stdenv-updates/; revision=9771
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
URLs to http://nix.cs.uu.nl/dist/tarballs. With content-addressable
mirror support (r9190, NIXPKGS-70) this is no longer necessary:
fetchurl will try to download from that location automatically. So
we can keep the original URLs.
svn path=/nixpkgs/trunk/; revision=9192
* 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
* To prevent this kind of thing, check that all tools are statically
linked.
* Use findutils 4.2.27, 4.2.28 doesn't build with dietlibc.
svn path=/nixpkgs/trunk/; revision=6881
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
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
