The default target (i386-linux) causes flags like "-march i386" to be
added, which breaks on recent Fedora releases (18 and up), resulting
in errors like:
/usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/atomicity.h:48: undefined reference to `__atomic_fetch_add_4'
So set the target to i686-linux.
http://hydra.nixos.org/build/6567357
We cannot pass the --{enable,disable}-executable-dynamic flags to GHC
versions prior to 7.4.x.
Building shared libraries via --{enable,disable}-shared is possible in theory
with GHC 6.12.x or later, but doesn't work in practice because our GHC 6.10.x
builds don't provide shared versions of their base libraries. This could
probably be fixed, but it's probably not worth the effort.
enableSharedLibraries configures Cabal to build of shared libraries. This
option requires that all dependencies of the package have been compiled
for use in shared libraries, too.
enableSharedExecutables configures Cabal to prefer shared libraries when
linking executables.
This patch partly fixes issue #1084.
Kept the old hacks where they don't break the build in case they things
they fix are still relevant.
I checked that the upgrade doesn't break:
1) Asymptote and EProver builds.
2) My XeLaTeX demo from configurations/ repository.
3) Some of my own files.
The upgrade fixes problems with simultaneous use of 3D and LaTeX labels
in Asymptote.
Please provide a test that worked previously and is broken now if you
need to revert this update or its parts.
The dns packages requires this feature, because it ships two test programs: one
of them requires network access (so we cannot run it), but the other test does
not. Setting testTarget appropriately allows us to run only one of the two
suites.
Haskell packages that contain non-ascii characters in their .cabal file
or somewhere else in their haddock documentation fail to compile under
nixpkgs and usually flagged with noHaddock = true. I wanted to do the
same for modularArithmentic, when I realized that we just have to set
the locale to some UTF-8 compatible locale in build-support/cabal to fix
this issue correctly.
Wheezy has been released on June 15th and on all mirrors the SHA256 hash
of Packages.bz2 has changed to reflect the new release, so let's update.
Here is the release announcement from Debian:
http://www.debian.org/News/2013/20130615
It also seems that the versioning scheme has changed in version 7.x, so
they seem to have switched to a two digit versioning scheme. This means,
that the attribute name "debian70..." should really be something like
"debian7...", but I'm keeping the attribute as-is to not break
references.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is needed in order to prevent services from starting while
populating the image with the contents of the .deb files. The procedure
used here is exactly the same as used in debootstrap.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
9p (with caching enabled) is much faster than CIFS and doesn't require
Samba or virtual networking. For instance, building GNU Hello with
CIFS takes ~323s on my laptop, but with 9p it takes 54s.
More measurements will be needed to see if "cache=fscache" is really
faster than "cache=loose" (the former seems to be a little bit
faster).
GCC provides a number of libraries that are used by programs built by
GCC, in particular libgcc_s.so and libstdc++.so. This caused programs
that used these libraries to have a runtime dependency on all of GCC
(~77 MiB). Now they only depend on the "lib" output of GCC (~1.6
MiB).
With this and previous multiple-output improvements, closure sizes are
reduced a lot:
hello: 41 MiB -> 22 MiB
patchelf: 118 MiB -> 23 MiB
pan: 364 MiB -> 90 MiB
This reduces the size of closures a lot by getting rid of Glibc's
header files, static libraries and utilities. For instance, the
closure of GNU Hello went from 41 MiB to 22 MiB.
TODO: We may want to merge back in parts of Glibc that we previously
split off (such as the info files).
This only ever worked because runInLinuxVM happened to call
overrideDerivation, which itself erroneously passed arbitrarily-added
attributes to the new call to derivation.
Hopefully this time Eelco won't have to revert my change ;)
Signed-off-by: Shea Levy <shea@shealevy.com>
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
The wrapper script accumulated some cruft over the last couple of months
because we did changes in freaky ways to avoid triggering re-builds of all
Haskell packages. Most of these kludges have been thrown out now.
This patch doesn't change the behavior of the wrapper except for one thing: the
internal helper scripts "ghc-get-packages.sh" and "ghc-packages.sh" are no
longer installed in the bin directory of the generated derivation.
The previous implementation used the following tying-the-knot trickery to
override 'doCheck' to false for the given build:
cabalNoTest = {
mkDerivation = x: rec {
final = self.cabal.mkDerivation (self: (x final) // { doCheck = false; });
}.final;
};
That seemed to work, but for some reason it caused trouble with some builds --
not all -- that use jailbreakCabal. The problem was the 'stdenv' attribute
couldn't be evaluated properly anymore:
$ nix-build ~/pkgs/top-level/release-haskell.nix -A optparseApplicative.ghc6104.x86_64-linux --show-trace
error: while evaluating the attribute `drvPath' at `/nix/store/qkj5cxknwspz8ak0ganm97zfr2bhksgn-nix-1.5.2pre3082_2398417/share/nix/corepkgs/derivation.nix:19:9':
while evaluating the builtin function `derivationStrict':
while instantiating the derivation named `haskell-optparse-applicative-ghc6.10.4-0.5.2.1' at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:40:13':
while evaluating the derivation attribute `configurePhase' at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:107:13':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/lib/strings.nix:55:26':
while evaluating the attribute `outPath' at `/nix/store/qkj5cxknwspz8ak0ganm97zfr2bhksgn-nix-1.5.2pre3082_2398417/share/nix/corepkgs/derivation.nix:18:9':
while evaluating the builtin function `getAttr':
while evaluating the builtin function `derivationStrict':
while instantiating the derivation named `jailbreak-cabal-1.1' at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:40:13':
while evaluating the derivation attribute `nativeBuildInputs' at `/home/simons/.nix-defexpr/pkgs/stdenv/generic/default.nix:76:17':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/lib/lists.nix:135:21':
while evaluating the attribute `buildInputs' at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:22:17':
while evaluating the builtin function `filter':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:22:60':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/top-level/haskell-packages.nix:119:17':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/lib/customisation.nix:61:22':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/lib/customisation.nix:56:24':
while evaluating the builtin function `isAttrs':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/development/libraries/haskell/Cabal/1.14.0.nix:1:1':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/top-level/haskell-packages.nix:113:20':
while evaluating the attribute `final' at `/home/simons/.nix-defexpr/pkgs/top-level/haskell-packages.nix:114:7':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:9:5':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/stdenv/generic/default.nix:51:24':
while evaluating the attribute `meta.license' at `/home/simons/.nix-defexpr/pkgs/development/libraries/haskell/Cabal/1.14.0.nix:17:5':
infinite recursion encountered
I tried to figure out why this happens, but eventually gave up. The new
implementation passes an argument called 'enableCheckPhase' to the Cabal
builder, which determines whether the user-specified doCheck value has any
effect or not. Now, a normal override can be used to disable unit testing.
It's quite amazing that we've managed to pass incorrectly spelled command line
flags to Cabal for ages without ever noticing. :-)
The search path options --extra-{include,lib}-dirs are usually unnecessary,
because the build environment is set up such that gcc and ld find those headers
and libraries automatically, i.e. without needing extra flags. The bubble burst
on MacOS X, though, where the build of haskell-text-icu couldn't find the icu
library without manually setting DYLD_LIBRARY_PATH in that build. Fortunately,
cabal takes care of that issue if a correctly spelled --extra-lib-dirs flag is
passed.
- The option for cloning in nix-prefetch-bzr is removed
- ssl certificates are now ignored by fetchbzr
This means that no .bzr directory is downloaded. Without this change, the
hash of the result is unpredictable, probably because of timestamping in the
.bzr directory.
Currently, the only package using fetchbzr is kicad.
There are some SVN repositories out there which don't have revision information
tied to externals. By using ignoreExternals, fetchsvn won't fetch these
externals anymore, so the fetch won't fail with a checksum mismatch, should
there be some changes in some of those external repositories.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
An aggregate is a trivial build that depends on other builds. This is
intended to provide a declarative replacement of Hydra's "view"
mechanism.
For instance, you can define an aggregate named "critical" that
depends on a selected set of jobs:
critical = releaseTools.aggregate
{ name = "foo-${tarball.version}";
members =
[ tarball
build.x86_64-linux
...
];
meta.description = "Release-critical builds";
};
The "critical" build will only succeed if all its members
(dependencies) succeed.
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.
uses for its core libraries, so that these files integrate seamlessly into one
profile, living right next to each other. This change is eventually going to
simply our with-packages wrapper quite a bit.
This branch refactors xfce and updates it to 4.10. I had been hoping to
find someone besides Vlada to test this (I don't use xfce), but no one
has come forward yet in 2 weeks so if this breaks something they can
make an issue or fix it. It all looks good by inspection.
According to <http://hackage.haskell.org/trac/ghc/ticket/4013>, this
feature won't work with XCode versions older than 3.2.
This means that Mac users will have considerably larger binaries because
some build-time dependencies (such as HTTP) will be mis-detected as
run-time dependencies.
In the master branch, doCheck defaults to 'false', which means that no package
will change its hash unless its doCheck field is set to 'true' explicitly. In
the stdenv-updates branch, however, all Haskell packages have a default setting
of 'doCheck=true'. Once that branch has been merged, filtering doCheck is no
longer necessary.
Conflicts:
pkgs/applications/networking/browsers/chromium/default.nix
pkgs/top-level/all-packages.nix
Merge conflicts seemed trivial, but a look from viric and aszlig would be nice.
This patch configures all Cabal builds with '--enable-split-objs' unless the
Nix expression explicitly sets "enableSplitObjs = false". The Cabal manual [1]
describes this option as follows:
| The GHC -split-objs reduces the final size of the executables that use the
| library by allowing them to link with only the bits that they use rather
| than the entire library. The downside is that building the library takes
| longer and uses considerably more memory.
One immediate benefit of this change is that the 'darcs' closure defined in the
top-level no longer refers to GHC. The same is probably true with other
executable packages.
[1] http://www.haskell.org/cabal/users-guide/installing-packages.html#setup-configure
The use case is to do a deep replacement of a dependency without rebuilding the entire tree.
For example, suppose a security hole is found in glibc and a patch released. Ideally, you'd
just rebuild everything, but that takes time, space, and CPU that you might not have, so in
the mean time you could build a safe version of, say, firefox with:
firefox-safe = replace-dependency { drv = firefox; old-dependency = glibc; new-dependency = patched-glibc; };
Building firefox-safe will rebuild glibc, but only do a simple copy/string replacement on all other dependencies
of firefox. On my system (MBP 13" mid-2012), after a new glibc had been build building firefox took around 11 seconds.
See the comments in the file for more details.
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).
Added support code for comfortable writing of upstream data update
expressions that do not require change of layout of the updated
expressions (although they make assumptions about single assignment per
line). Also added a default for choosing file to update (it is supposed
to be default.nix in the same directory) and a one-liner for typical
sourceforge redirects (and sourceforge mirror:// handling).
Replacing SBCL upstream tracking expression with a new version in a new
format.
Minuses: gave up on defining everything in Nix language (now update
expression is a series of actions to do when downloading fresh release,
it is actually interpreted by shell), now Nix expression contains
meaningful whitespace (the area to regenerate is determined by the
line with a specific comment and the closing brace on the otherwise
empty line).
Plusses: only one extra file which could even be moved out-of-tree if
desired, clean semantics for traversing multiple links (it is not found
in either Debian uscan or Gentoo euscan), the main expression is in one
file and is less different from usual style.
Jailbreaks-cabal allows Nixpkgs maintainers to quick-fix builds of packages
that over-specify their version requirements by removing the version
restrictions of all dependencies from the Cabal file. Set
jailbreak = true
in the build expression to activate this feature.
Some packages have a runtime dependency on libltdl, but shouldn't
depend on the rest of libtool (which in turn depends on binutils and
other stdenv tools). For example, splitting off libltdl cuts about 35
MiB from the closure of PulseAudio.
This feature sounds crazy, but it is used in some configure scripts (e.g. xbmc).
This patch causes an almost complete rebuild of Nixpkgs.
Patch submitted by Jan Malakhovski <oxij@oxij.org>.
apparently doesn't allows underscores in version strings, so we
replace them by dashes. This is the exact opposite of RPM, which
doesn't allow dashes.
svn path=/nixpkgs/trunk/; revision=34220
"nix-env -i" profiles, as a container for flexible configuration at the style
of nixos, to be defined in .nixpkgs/config.nix, with the main target of
generating an activation script.
svn path=/nixpkgs/trunk/; revision=33445
extension postHook) does nothing else than set up the environment.
It shouldn't touch $out because there may not be a $out. So move
the "imperative" bits of postHook into a separate phase.
svn path=/nixpkgs/trunk/; revision=33249
Merge conflicts:
* unzip (almost trivial)
* dvswitch (trivial)
* gmp (copied result of `git merge`)
The last item introduced gmp-5.0.3, thus full rebuild.
+ensureDir->mkdir -p in TeX packages was catched by git but not svn.
svn path=/nixpkgs/branches/stdenv-updates/; revision=32091
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
There were conflicting patches of pkgs/os-specific/linux/module-init-tools.
Apparently, the expression was updated independently in both branches. I've
resolved the conflict by preferring the patches from stdenv-updates, because
those patches appeared to be more sophisticated, i.e. they build the manual,
etc.
svn path=/nixpkgs/branches/stdenv-updates/; revision=29680
created directories, which is a security risk. So create $out with
the proper permissions before starting the VM.
svn path=/nixpkgs/trunk/; revision=27095
path worth a "-rpath" entry.
This put a problem in the bootstrap, where we built 'zlib' and wanted to link programs with it, and while they got linked well, at runtime the boostrap-tools zlib came first on rpath becaue
the ld call was done with "-dynamic-linker ..." before "-lz".
I saw this trouble on the fuloong, where the zlib in boostrap-tools is not
runtime compatible with that binutils are linked to.
svn path=/nixpkgs/branches/stdenv-updates/; revision=25107
derivation instead of a string, but this did not cover all use cases we had.
Instead of updating the use cases, I made the wrapper accept also a string.
We saw this problem trying to build gcc43_multi.
svn path=/nixpkgs/branches/stdenv-updates/; revision=25029
now kills its process group when it exits. Without setsid, this
ends up killing the parent (i.e., the builder).
* Use port 445 instead of 139 because the CIFS kernel module tries
port 445 first. If there is an actual Samba running on the host, it
would end up connecting to that one instead of our own and fail.
svn path=/nixpkgs/trunk/; revision=25017
dependencies with it. (I should never link ld.so with a NIX_LDFLAGS -rpath
forced)
I made vim, scummvm cross-build. I added prboom (that cross-builds).
Mplayer and elinks don't cross-build fine still, but are on the way.
The mplayer fails to build in a weird way; nix does not show either a gcc
error message or even the 'make' error message.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23131
but on a nix-store path only having the cross-built gcc libraries.
This trims down a lot the runtime dependency tree for cross-built packages.
I also remove the glibc dependency on the native bash.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23040
I tried to fix some trivial conflicts.
I don't know if I merged well some more difficult conflicts on openssl/darwin_patch
or haskell-platform.
svn path=/nixpkgs/branches/stdenv-updates/; revision=22878
properly on Amazon EC2.
* Always apply the CIFS timeout patch. It's rather annoying to have
to build a separate kernel for the VM tests.
svn path=/nixpkgs/trunk/; revision=22630
operations to 120s. This is necessary if the host is heavily
loaded. For instance, in the Hydra build farm, if there are many
concurrent jobs, VM builds often fail because they hit the timeout.
svn path=/nixpkgs/trunk/; revision=22347
* Use socat's "exec" and "nofork" options to reduce the number of
processes. Also, if smbd exits abnormally, exit from the smbd
restart loop.
svn path=/nixpkgs/trunk/; revision=22279
-no-kvm-irqchip flag, and on the Hydra machines only works on the
rather old KVM 76. So as a workaround, don't use -smb, but use
QEMU's "guestfwd" feature to forward 10.0.2.4:139 in the guest to a
Unix domain socket on the host connected to Samba.
* Use "cache=writeback" to improve performance a lot.
* Use "werror=report" to make QEMU crash instead of hang if the host
filesystem is full.
svn path=/nixpkgs/trunk/; revision=22249
it properly put the rpath for directly passed .so files, and additionally it
works much faster than the old ld-wrapper.
svn path=/nixpkgs/branches/stdenv-updates/; revision=21978
on the next stdenv-updates.
This would fix the build for many cmake packages, although that requires updating the stdenv
in those for its gcc to use this 2nd wrapper.
I updated paraview and avidemux. I can't recall now more packages with problems, but I was
quite sure there were.
If anyone sees a cmake-built package with the result binaries lacking some rpaths, then try
this wrapper.
svn path=/nixpkgs/trunk/; revision=20669
cross-building nixpkgs implementation, were not referenced anywhere.
This new busybox builds natively, and also cross-builds with uclibc.
I updated the uclibc config with a busybox defconfig requirement (something about RPC).
I made the gcc-cross-wrapper properly set the dynamic loader to programs.
After this, 'qemu-arm' can run the dynamically linked busybox cross built for armv5tel--linux-gnueabi.
svn path=/nixpkgs/trunk/; revision=20514
I introduce the new nixpkgs parameter "platform", defaulting to "pc",
which was before defined as an attribute of nixpkgs.
I made the crossSystem nixpkgs attribute set parameter contain its own 'platform'.
This allows cross-building a kernel for a given crossSystem.platform in a non-PC
platform.
The actual native platform can be taken from stdenv.platform, and this way we also
avoid the constant passing of 'platform' to packages for platform-dependant builds
(kernel, initrd, ...).
I will update nixos accordingly to these changes, for non-PC platforms to work.
I think we are gaining on flexibility and clearness. I could cross build succesfully
an ultrasparc kernel and a mipsel kernel on PC. But since this change, I should be able
to do this also in non-PC.
Before this change, there was no possibility of distinguishing the "target platform" or
the "native build platform" when cross building, being the single "platform" attribute
always interpreted as target platform.
The platform is a quite relevant attribute set, as it determines the linuxHeaders used
(in the case, by now the only one supported, of linux targets).
The platform attributes are quite linux centric still. Let's hope for more generality to come.
svn path=/nixpkgs/trunk/; revision=20273
because it makes linking very slow. Use bash's =~ operator instead
(and only once for each argument). We depend on bash already anyway
because of arrays so it's not a problem.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19699
something'.
It should not link at least for '-x c-header' and '-x c++-header', and maybe
link for '-x c' or '-x c++', but we expect noone will be linking using these
later strings.
Adding opencv, which required '-x c-header' working, and that's why I have
updated gcc wrapper.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19491
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
ghdl-wrapper.
I made the gcc-4.3.4 expression allow the 'vhdl' language through ghdl.
The ghdl developer recommends this gcc version; maybe it would work with
gcc-4.4. If not this ghdl version, maybe next versions.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19071
broke the evaluation of nixpkgs.
I also tried to make the gnat wrapper friendly to any gnat installation, not
only gnatboot.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19062
Some things don't work:
- The ghdl expression (it still needs the gcc 4.3.4 src, ...)
- The gnat wrappers need to be more generic - now they work only for the
given gnatboot (taken from gentoo) and gnats installed to their $out
store path.
- Using the cloogppl and ppl. We will need our own gnatboot built with c++
libraries for that.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19060
sheevaplug kernel, so the kernel does not build in the sheevaplug right now.
I will try to fix that in next commits.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19045
regexp looking for such ld arguments did not work well with "--soname=xxx.so".
Now I added the condition that the argument should not start with a hyphen, for
it to be possibly considered a .so file to link with.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18919
Removing any reference to the gcc-wrapper2, as now the gcc-wrapper already conveys
the changes, I created gcc-wrapper2 in trunk for.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18913
source regions which are substituded by the tool nix-repository-manager.
See http://github.com/MarcWeber/nix-repository-manager/raw/master/README.
sourceByName is called sourceFromHead now.
updates: MPlayerTrunk, haxe, neko, netsurf, cinelerra, ctags
cinelerra does no longer build due to Xorg update
svn path=/nixpkgs/trunk/; revision=18894
stdenv.
In this gcc-wrapper2 I made the ld-wrapper.sh to handle the linking with shared
objects through direct pass as ld command arguments of the absolute path to shared
objects, instead of using the -L/-l combinations.
cmake 'FindXXX.cmake' modules make a strong usage of the dynamic linking directly
passing the absolute path to the shared object to the linker, and as our wrapper did
not add any -rpath for those, writting the nix expressions for some cmake packages
resulted in a lot of tricks, compared to using this gcc-wrapper2.
This gcc-wrapper2/ld-wrapper.sh should become the gcc-wrapper/ld-wrapper in a
stdenv update.
I also updated some cmake expressions to use this gcc-wrapper2, and reduced its
tricks.
I also updated the cmake setup-hook for it to make cmake not touch any rpath decided
at build time, when running the 'make install' of makefiles created by cmake.
svn path=/nixpkgs/trunk/; revision=18885
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
native strip. So we now distinguish dontStrip and dontCrossStrip. I updated
the expressions for glibc-2.9 and glibc-2.11 accordingly.
I could get rid of the cross-glibc depending on the cross-gcc-stage-static.
Enabling nls in the final cross-gcc.
I still have problems on wint_t/wchar_t not working on cross build. Gettext
does not build.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18562
- 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
- Stating better the guile dependencies (native/host) for guile to build
- Fixing cross-linking, through --rpath-link (ld(1) explains well about it
- Made gcc call the linker and the assembler through the gcc wrapper instead of
directly. I thought this was the source of missing -rpath's, but the source
of the problem ended up being the lack of --rpath-link. But I think the
native gcc calls the wrapped ld and as, so let's do the same cross
compiling.
- Removed the binutilsCross from the glibc expressions. Now they are built
using the gcc-cross-wrapper, and they were built with the direct gcc and
binutils before this change.
- I think patchelf and strip don't break the cross-compiled binaries, so I
reallow them on cross compilation.
- I disable the checkPhase on cross compilation. This made gmp and libtool
fail when cross compiled, iirc.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18498
linking path), and with this achieved bash being cross-compilable.
I fixed the few expressions involved in bash building, so they have well stated
native and non-native inputs.
I also tried to cross-build guile, and with this I found a problem in the
actual cross-gcc: it calls the binutils ld, instead of the ld wrapper. This
way, the programs/shared_libraries don't get the proper -rpath.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18497
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 `--depth' argument asks Git to fetch the last revisions of the given
repo on *any* branch, which is often useless.
Thanks to Lluís Battle for clarifying this.
svn path=/nixpkgs/trunk/; revision=18438
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
I think it takes the recent N commits into the repository, which says very little,
even for wanting master/HEAD.
svn path=/nixpkgs/trunk/; revision=18277
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
works on Red Hat Linux, i.e. that is based on glibc version 2.5.
Furthermore, this patch fixes a number of gcc 4.3.3 build errors in glibc 2.5
that occur on both x86 and x86_64. The older version of this library is still
useful for running Nix on a Red Hat host. Newer version of glibc fail to detect
the kernel's capabilities correctly (due to mad patches applied to the kernel
by Red Hat).
The individual changes are:
* Re-activated glibc 2.5 in all-packages.nix.
* Fix incomplete header search path in bootstrap tools.
Gcc-wrapper sets "-B<prefix>" to tell the compiler about its installation
root. Unfortunately, the setting doesn't add $gcc/lib/gcc/*/*/include-fixed
to the search path. That directory is required, however, because it contains
the system-specific "limits.h" file, and the glibc 2.5 builds tries to find
that file via #include_next.
* Support intrinsic functions like __signbit() or atof() correctly to avoid
compile-time conflicts.
* Switch to NPTL. Linuxthreads is no longer supported.
* Added a meta attribute to glibc package.
* Updated nixUnstable to version 0.13pre15614 from trunk. The previous version
failed regression tests.
* Fix more strict type checking in binutils since 2.18.50.0.3.
Without this patch, the build failed on x86, saying:
../sysdeps/i386/fpu/ftestexcept.c: Assembler messages:
../sysdeps/i386/fpu/ftestexcept.c:33: Error: suffix or operands invalid for `fnstsw'
svn path=/nixpkgs/branches/stdenv-updates/; revision=16037
* Added dsymutil to gcc wrapper env on darwin
* turned off make check for gnugrep on darwin
* added --enable-bsd=libs configure flag for gnugrep on darwin
svn path=/nixpkgs/trunk/; revision=16014
in the Nix expression evaluator (namely that comparison of attribute
sets works properly).
* Removed some redundant parentheses in builder-defs.
svn path=/nixpkgs/trunk/; revision=15551
modules for the initial ramdisk if there were no additional kernel
module packages (such as the NVIDIA driver or AUFS), leading to a
kernel panic in the initrd. This was because in that case modprobe
would print paths referring to the kernel path rather than the
module aggregation path, and then `sed "s^$kernel^$out^"' would
silently fail. Fixed.
* Also, use depmod here rather than doing sed hackery on modules.dep.
* Also, `allowMissing' was broken (missing "$" before the variable
name).
svn path=/nixpkgs/trunk/; revision=15394
builders. These are redundant now.
* Inlined some trivial builders.
* Removed a few explicit setup-hook creations. This is done
automatically now if setupHook is set.
* Deleted the initscripts package. NixOS doesn't use it anymore.
svn path=/nixpkgs/branches/stdenv-updates/; revision=15276
* 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
otherwise aclocal barfs. Updated the builder to use makeWrapper
* Made Automake 1.10 the default.
* Fixed `make check' in Automake by turning off indented logging in
Make (there is a flag for that now).
* Disabled the `make check' in Automake by default because it takes a
REALLY long time (e.g. more than 2 hours on Cygwin, 50 minutes on
Darwin, 25 minutes on Linux) which is a lot for a package that
otherwise takes 10 seconds to build. We can add a Hydra job with
doCheck enabled to do regression testing.
* make-wrapper: allow --run commands to add additional flags to the
invocation of the wrapped program. An example is the aclocal
wrapper: it adds additional -I ... flags.
* make-wrapper: call the wrapped program .foo-wrapped instead of
.wrapped-foo to make it easier to tell programs apart in `ps'
output.
svn path=/nixpkgs/branches/stdenv-updates/; revision=14885
* Added a function binaryTarball to do a DESTDIR build into
/usr/local. Useful for making statically linked binaries. However,
it may be better to do this in a VM (since if you do it in a Nix
build environment, you can still end up with a lot of Nix
dependencies in your binaries, even if you do static linking).
svn path=/nixpkgs/trunk/; revision=14726
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
"*.tar.bz2 *.tar.gz" and there are no *.tar.gz files. Maybe we
should turn this on in stdenv (nullglob just seems like the right
thing to do in general).
svn path=/nixpkgs/trunk/; revision=14606
of Hydra builds more distinct (e.g. "patchelf-build-0.5pre1234"
instead of just "patchelf-build"). If the version isn't known,
append at least the revision.
* Propagate the release name of the source tarball to Nix builds.
Useful to provide sensible package names in channels.
svn path=/nixpkgs/trunk/; revision=14294
* Create some device nodes in the RPM/Deb disk images, since modern
distributions may not provide any device nodes (they're all
generated by udev).
svn path=/nixpkgs/trunk/; revision=14293
image, otherwise the post-installs script of the "passwd" package
will fail because /etc/login.defs is missing. This also fixes the
Ubuntu 8.10 image generation, woohoo!
svn path=/nixpkgs/trunk/; revision=14217
* Put the Glibc linker flags in front of the GCC linker flags. Needed
for the stdenv-linux bootstrap.
svn path=/nixpkgs/branches/stdenv-updates/; revision=13940
should fix previous problems with GCC 4.3 in compiling C++ code
where e.g. <cassert> has to appear before <assert.h> in the search
path due to the former's use of #include_next. The previous "fix"
broke compilation of C code by placing the C++ include directory
before the Glibc include directory (which would barf on
e.g. <complex.h>, which appears in both).
svn path=/nixpkgs/branches/stdenv-updates/; revision=13806
* checkinstall: get rid of the RUNPATH in the LD_PRELOAD library so
that it works with native Glibc (e.g. in VM builds).
* debBuild: use our own checkinstall. In particular this allows us to
build Debs on x86_64.
svn path=/nixpkgs/trunk/; revision=13608
we run into trouble on Fedora 10 (RPM 4.6), where the default is no
longer /usr/src/something but $HOME/something.
svn path=/nixpkgs/trunk/; revision=13466
by Pjotr Prins a while back. This could also be used to generate
RPMs for packages that don't have a spec-file.
* Added checkinstall to Nixpkgs. However we don't use our own build
yet because with it "make install" segfaults in a Debian VM, while
the pre-built binary does work.
svn path=/nixpkgs/trunk/; revision=13400
(e.g. making source tarballs, doing coverage analysis) to the
Nixpkgs tree. This makes it easier to run build farm jobs locally
since you don't need to check out the "release" tree separately.
Also it means one less input to declare for build farm jobs.
* Removed succeedOnFailure and separate logging of phases. Hydra
doesn't need that.
svn path=/nixpkgs/trunk/; revision=13388
* Updated Debian 4.0 to r4a. Dropped the revision ("r3", "r4a") from
the attribute name since Debian doesn't seem to keep old revisions
available anyway.
svn path=/nixpkgs/trunk/; revision=12849
for userspace networking / Samba again.
* vmtools: use KVM 74 and Linux 2.6.26, and use virtio for networking
/ disk access.
svn path=/nixpkgs/trunk/; revision=12768
fetchurl instantiations, instead of passing the mirrors to fetchurl
instantiations via environment variables. This makes the resulting
store derivations (.drv files) much smaller, which in turn makes
nix-env/nix-instantiate faster (4.8 -> 4.2 seconds on nix-env -qa
--out-path).
svn path=/nixpkgs/trunk/; revision=12695
* An attribute `stdenv_32bit' that returns a stdenv capable of
building 32-bit binaries.
* grub: build on x86_64-linux.
svn path=/nixpkgs/trunk/; revision=12211
libstdc++ headers in the header search path, otherwise libstdc++'s
use of #include_next to include Glibc headers breaks.
svn path=/nixpkgs/trunk/; revision=12195
* rss-glx: fixed the build.
* Removed the OpenGL wrapper stuff, it's no longer needed (thanks to
the RUNPATH you just need to put the appropriate libGL.so in the
LD_LIBRARY_PATH).
svn path=/nixpkgs/trunk/; revision=12093
image (i.e., it can contain any OS that obeys the interface
documented in the comment). See `testFreeBSD' for an example that
performs a build of the ATerm library on FreeBSD 7.0. This will be
used in the build farm to perform builds for platforms for which we
cannot synthesize VM images automatically.
svn path=/nixpkgs/trunk/; revision=11753
* In addition to the `diskImages' set, there now is a `diskImageFuns'
set that holds functions to build a disk image for a specific
distribution, given a list of names of top-level packages that
should be included in the image. This makes it easier to customise
an image (e.g. if you want to build an RPM in an image with some
very specific dependencies that aren't in the default image).
* Added Fedora 6.
svn path=/nixpkgs/trunk/; revision=11513
expression for a Debian closure automatically (so that we don't have
to remember to regenerate those files ourselves). The `import
<derivation>' feature generally shouldn't be used in Nixpkgs, but
since it's only used in the buildfarm it should be fine.
svn path=/nixpkgs/trunk/; revision=11512
from the "primary.xml.gz" file of Fedora and OpenSUSE distributions.
Analogous to the Deb closure generator.
* Image for Fedora 8.
svn path=/nixpkgs/trunk/; revision=11510
- fetchdarcs_2pre added
- flapjax added
- no longer used : annotatedDerivations
- added bleeding edge repos with a tiny nix repository manager which dowloads and
updates repostiries, then creates tar.gz dist files which are used by bleeding_edge_source
(darcs tested only by now)
- added experimental my_environment with example
svn path=/nixpkgs/trunk/; revision=10974
- fetchdarcs_2pre added
- flapjax added
- no longer used : annotatedDerivations
- added bleeding edge repos with a tiny nix repository manager which dowloads and
updates repostiries, then creates tar.gz dist files which are used by bleeding_edge_source
(darcs tested only by now)
- added experimental my_environment with example
svn path=/nixpkgs/branches/stdenv-updates/; revision=10973
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
This is so that the Unison wrapper can be generated with
makeWrapper.
* Use makeWrapper as a buildInput everywhere.
* Updated BitTorrent, cvs2svn.
svn path=/nixpkgs/trunk/; revision=10213
a wrapper script. E.g.
wrapProgram $out/bin/prog --set FOO bar
will create a wrapper around "prog" so that the environment variable
FOO is set to bar. The original program is renamed to
$out/bin/.wrapped-prog.
* Function makeSetupHook to convert a script into a setup hook which
can be included in buildInputs. This makes it easier to use scripts
like makeWrapper.
* Added Bazaar, yet another distributed version management system.
svn path=/nixpkgs/trunk/; revision=10211
mirror:// sites through environment variables, e.g.
NIX_MIRRORS_gnu="ftp://ftp.nluug.nl/pub/gnu/ ftp://ftp.gnu.org/pub/gnu/"
or
NIX_MIRRORS_sourceforge="http://surfnet.dl.sourceforge.net/sourceforge/"
svn path=/nixpkgs/trunk/; revision=9302
fetchurl {
url = http://heanet.dl.sourceforge.net/sourceforge/zapping/zapping-0.9.6.tar.bz2;
md5 = "8306775c6a11de4d72345b5eee970ea6";
};
you can write
fetchurl {
url = mirror://sourceforge/zapping/zapping-0.9.6.tar.bz2;
md5 = "8306775c6a11de4d72345b5eee970ea6";
};
which causes fetchurl to try the SourceForge mirrors listed in the
`sourceforge' attribute in build-support/fetchurl/mirrors.nix.
(They're currently tried in sequence, and the lists of mirrors are
not configurable yet.)
The syntax for mirror URLs is mirror://site/path/to/file, where
`site' is currently one of `sourceforge', `gnu' (mirrors of
ftp://ftp.gnu.org/pub/gnu) and `kernel' (mirrors of
http://www.all.kernel.org/pub/).
svn path=/nixpkgs/trunk/; revision=9197
fetching a file with hash HASH of type TYPE, we first try to
download <base-url>/<type>/<hash>, where <base-url> is one of a list
of mirrors. For instance, given
src = fetchurl {
url = http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.6/source/firefox-2.0.0.6-source.tar.bz2;
sha1 = "eb72f55e4a8bf08e8c6ef227c0ade3d068ba1082";
};
and the mirror list [http://nix.cs.uu.nl/dist/tarballs], we first
try to download
eb72f55e4a
and if that fails, we use the original URL.
The list of mirrors is not yet user-configurable.
* `fetchurl' now also accepts an argument `urls' instead of `url' for
a list of alternative download locations, which fetchurl will try in
sequence.
svn path=/nixpkgs/trunk/; revision=9190
can be installed in a user environment without conflict. This is
useful if you need gcov (which isn't symlinked in the GCC wrapper).
svn path=/nixpkgs/trunk/; revision=8809
to the gcc invocation.
If we pass a flag like -Wl, then gcc will call the linker unless it
can figure out that it has to do something else (e.g., because of a
"-c" flag). So if no non-flag arguments are given, don't pass any
linker flags. This catches cases like "gcc" (should just print
"gcc: no input files") and "gcc -v" (should print the version).
svn path=/nixpkgs/trunk/; revision=8644
* 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
* 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
`@var@' in the file `src', writing the result to $out, where `var'
is any environment variable starting with a lowercase character.
Example:
genericSubstituter {
src = ./file;
foo = "bla";
shell = bash + "/bin/sh";
};
will replace `@foo@' with `bla' and `@shell@' with
`/nix/store/...-bash-.../bin/sh'.
svn path=/nixpkgs/trunk/; revision=6928
we use the GCC wrapper in a user environment, the wrong assembler
will be called. This is not usually a problem, but sometimes it is
(e.g., when using G++ 4.1.1 with binutils 2.16 or so).
svn path=/nixpkgs/trunk/; revision=6862
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
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
Even though you could just inherit binutils it is conceptually cleaner (I
think) to make these tools available here.
svn path=/nixpkgs/trunk/; revision=4967
* added an experimental fetchdarcs function, based on fetchsvn
(there are no expressions yet that use this function)
svn path=/nixpkgs/trunk/; revision=4615
in /usr/lib/libGL.so.1 (which will typically load a driver in
/usr/X11R6/lib/modules/dri). This has been tested on a i915
graphics card; it should work with most open source X.org drivers.
For NVidia's proprietary drivers (which we cannot build ourselves
anyway), some more symlinks are necessary; I'll add those later.
So to get hardware-accelerated Quake 3, do:
$ nix-env -p /nix/var/nix/profiles/opengl -i xorg-sys-opengl
$ nix-env -i quake3-demo
$ quake3
svn path=/nixpkgs/trunk/; revision=4613
allow the OpenGL implementation to be overriden through the
OPENGL_DRIVER environment variable. If it is not set, we use the
implementation installed in the profile
/nix/var/nix/profiles/opengl, allowing easy late binding by the
user, e.g.,
$ nix-env -p /nix/var/nix/profiles/opengl -i nvidia-sys-opengl
might install the NVidia OpenGL implementation.
The code that does this is not specific to Quake 3: it has been
factored out into build-support/opengl/mesa-switch.sh. Presumably
any application that requires hardware-accelerated OpenGL needs it.
* Add the Quake 3 demo to the cache.
svn path=/nixpkgs/trunk/; revision=4612
server's certificate. This is perfectly safe: we don't care whether
the server is being spoofed --- only the cryptographic hash of the
output matters.
svn path=/nixpkgs/trunk/; revision=4377
right thing. This is necessary to make libtool detect g++
properly. (Fixes the `libtool: compile: unable to infer tagged
configuration' error on FreeBSD when building Berkeley DB 4.4.)
svn path=/nixpkgs/trunk/; revision=4370
* Use the system Perl on all non-i686-linux platforms.
* Don't build Python support in libxml2 on most platforms.
svn path=/nixpkgs/trunk/; revision=3019
`*.dll.config' files corresponding to CLR assemblies. I.e., the
full path to native libraries is included in the maps. In effect
this allows us to set the equivalent of an RPATH for assemblies.
* gtk-sharp: use the DLL fixer. It's not perfect yet: I still have to
set the LD_LIBRARY_PATH for monodoc to include the gtk-sharp lib
directory itself, so that it can find the `*sharpglue.so' files.
This seems to be gtk-sharp's fault; it doesn't have an entry for
those libraries in its DLL maps.
svn path=/nixpkgs/trunk/; revision=2330
this contains mostly Armijn's pure stdenv-linux.
* After unpacking the statically linked GCC, patch all store paths to
/nix/store/ffffffffffffffffffffffffffffffff. Ugly hack to prevent
undeclared references but it works.
* We don't need Glib's dynamic libraries in the first bootstrap stage;
delete them. Actually the downloaded Glibc binary is only needed
for building Glibc, since GCC needs a C compiler to build some
programs in `configure'. So static linking is fine for that. Maybe
it would be better to patch `configure' so that we don't need a
pre-built Glibc at all.
* Set the svn:executable property on `cp' and `patchelf'.
* In Glibc, revert to LinuxThreads. Maybe NPTL will work, but TLS
support is a problem.
* Delete most Glibc patches; they're no longer needed since the branch
updated it to 20050110.
* Some cleanups.
svn path=/nixpkgs/trunk/; revision=2258
files easier. Examples:
substitute inputFile outputFile \
--replace "@bindir@" "$out/bin" \
--replace "@gcc@" "$GCC/bin/gcc"
substitute inputFile outputFile --subst-var out
(this is sugar for --replace "@out@" "$out")
substituteInPlace file --replace a b
(input and output are both `file'; the execute bit is preserved)
svn path=/nixpkgs/trunk/; revision=2239
the tree being fetched from a Subversion repository. The revision
number is now optional (and defaults to HEAD).
This makes `fetchsvn' more pure. First, a URL/revision tuple does
not uniquely identify a file resource, since the repository itself
might change. Second, `svn:external' attributes can cause arbitrary
resources to be exported.
A script `nix-prefetch-svn' has been provided to determine the hash
of a URL.
svn path=/nixpkgs/trunk/; revision=938
libgcc of the gcc being built, not the gcc building it.
* Only include a directory in the rpath of an executable/library if it
is actually used. Before, the `/lib' directory of every build input
was added to the rpath, causing many unnecessary retained
dependencies. For instance, Perl has a `/lib' directory, but most
applications whose build process uses Perl don't actually link
against Perl. (Also added a test for this.)
* After building glibc, remove glibcbug, to prevent a retained
dependency on gcc.
* Add a newline after `building X' in GNU Make.
svn path=/nixpkgs/trunk/; revision=911
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
- gcc/ld-wrappers have been factored out into a separate
derivation. This allows a working gcc to be installed in the user
environment. (Previously the Nix gcc didn't work because it
needed a whole bunch of flags to point to glibc.)
- Better modularity: packages can specify hooks into the setup
scripts. For instance, setup no longer knows about the
PKG_CONFIG_PATH variable; pkgconfig can set it up instead.
- gcc not longer depends on binutils. This simplifies the bootstrap
process.
svn path=/nixpkgs/trunk/; revision=816
a big problem, so I decided to require to user to get the
file and put it in some location in the file system. wget
doesn't seem to accept the file scheme however, so I had to
move the copying into the builder itself. The builder checks
the md5 hash of the downloaded file. Maybe having a separate
'fetchfile' would be useful to make a file in the outside
world pure. I tried to add this to build-support, but this
obviously did not work. I still committed it. Just remove it
if you think that it sucks.
svn path=/nixpkgs/trunk/; revision=716