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
`selectVersion ./foo "bar"' instead of `import ./foo/bar.nix'.
* Replaced `with args' with formal function arguments in several
packages.
* Renamed several files to `default.nix'. As a general rule, version
numbers should only be included in the filename when there is a
reason to keep multiple versions of a package in Nixpkgs.
Otherwise, it just makes it harder to update the package.
svn path=/nixpkgs/trunk/; revision=18403
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
Add expression for ssreflect, an extension to the Coq Proof Assistant.
Still has some clitches (see TODO in default.nix) but is usable anyway.
svn path=/nixpkgs/trunk/; revision=18145
a symbol clash with glib 2.21. So we keep with glib 2.20.
I also changed the default wxGTK from 2.6 to 2.8, caring so no hash is changed due to
this change. Some packages using 2.6 may well build with 2.8, so we can try updating
them for another commit.
svn path=/nixpkgs/trunk/; revision=18133
The new version requires Tcl at build time in order to construct sqlite3.h,
even when the --without-tcl option is passed to configure. That feels odd
because the sqlite web site does advertise "no dependencies", but then it's
probably not a big deal either. The build of the Tcl plugin for sqlite is still
disabled, so there is no run-time dependency.
svn path=/nixpkgs/trunk/; revision=18091
http://www.psc.edu/networking/projects/hpn-ssh/
I tried to keep the openssh hash not changing, unless the user sets hpn in getConfig
style. I think that does not look as good as a patch changing the hash, but it may
annoy less. Let me know if it is not ok.
I don't think hpn should be the default, because it may have some insecurity implications
I don't know of. But I used to enable it in all my machines, and I hope to do so unless
advised otherwise.
svn path=/nixpkgs/trunk/; revision=18073
I tried their website renderer, but it did not work for me. It may be shut down,
because their last update is for 2006.
Next steps: put it into nixos, and build the renderer (java!).
svn path=/nixpkgs/trunk/; revision=18041
there seems to be a much cleaner solution than deepOverride, namely
call all-packages.nix with an appropriate packageOverrides set.)
svn path=/nixpkgs/branches/xorg-7.5/; revision=18025
development/libraries/{glib,gtk+,pango,atk,...}. Done for glib/gtk+
1.2. Also deleted some obsolete, unused versions (gtkLibs 2.10,
2.12, and 2.14).
svn path=/nixpkgs/trunk/; revision=17992
I could not easily make some bsdgames build or install. Too much patching
against the installer trying to write beyond the nix store.
svn path=/nixpkgs/trunk/; revision=17971
* Dropped "nolongdouble.patch". The patch no longer applies to Python 2.6, and
apparently isn't required anymore either.
* Added access to native Darwin arch utility. Python tries to run 'arch' in
the configure stage, but that binary reside in /usr/bin. To make it
available to the expression, the small wrapper darwinArchUtility is added as
a buildInput if appropriate.
* Don't pass --enable-shared. The build fails if we try to enable building of
shared libraries, apparently because some required libraries aren't linked,
i.e. the linker call isn't right.
TODO:
* Figure out how to enable shared linking.
* The resulting binary on Darwin seem to lack the binascii module.
svn path=/nixpkgs/trunk/; revision=17894
The build succeeds on i686-linux. Other platforms look good, too,
because there were hardly any changes necessary to update the expression
from 2.5.
svn path=/nixpkgs/trunk/; revision=17889
Updating libgpod
Making gtkpod accept 'ogg' files, and made it convert them well to mp3, if 'lame'
and oggdec is in path. It should better reference lame and libvorbis store path
files.
svn path=/nixpkgs/trunk/; revision=17888
On MacOS X, we used to use the native perl interpreter from /usr/bin.
Unfortunately, that interpreter fails to build a number of packages
(Subversion, Git, etc. ...), because it assumes knowledge about the
underlying C compiler that is not valid for the compiler used by Nix.
For example, /usr/bin/perl assumes that the compiler can build binaries
for both the ppc and the x86 architecture. /usr/bin/gcc can do that, but
the gcc from Nix can't.
The solution is to compile Perl 5.10 in Nix so that the ./configure
phase can properly detect the system's capabilities. However, note that
the resulting binary is impure: it will find headers in /usr/include and
libraries in /usr/lib. In this respect, the Nix-compiled perl binary is
no different than the native one in /usr/bin -- it's just configured
more accurately.
svn path=/nixpkgs/trunk/; revision=17870
