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
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
