`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
Redland's use of the pre-processor symbol SQLITE_API collides with a
symbol of the same name in sqlite 3.6.19. Patching the source code to
use REDLAND_SQLITE_API instead works around the problem.
svn path=/nixpkgs/trunk/; revision=18100
Sqlite has a build mode called "amalgamation" that gathers all 90+ source code
files into a single sqlite3.c file before compiling the library. Building
sqlite this way reportedly gives a 5-10% performance gain because the compiler
can perform more sophisticated optimizations.
svn path=/nixpkgs/trunk/; revision=18092
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
propagatedBuildInputs, because those inputs are required by the *.pc
or *.la files of the package:
- If a *.pc file references a non-propagated input, then Gnome
packages have the bad tendency to silently ignore this problem in
configure scripts - the failure of a command like `pkg-config
--cflags foo' will be ignored if a dependency of foo.pc is
missing, so no flags will be added, and the build will fail later
on a missing header or library.
- If a *.la file references a non-propagated input, the build will
also fail, because Libtool will add library dependencies that it
cannot find. (Arguably *.la files should never reference packages
that aren't in the corresponding *.pc file, but they do it
anyway).
By setting the propagatedBuildInputs properly, it should be possible
to get rid of all the NIX_CFLAGS_COMPILE / NIX_LDFLAGS hacks in the
Gnome expressions.
svn path=/nixpkgs/branches/xorg-7.5/; revision=18084
configuration directory so that users on other distributions don't
need to set $FONTCONFIG_FILE (NIXPKGS-29). Also use
/var/cache/fontconfig for the cache to prevent programs run by root
from writing into the Nix store.
svn path=/nixpkgs/branches/xorg-7.5/; revision=18021
patent-encumbered hinting and sub-pixel rendering. It's disabled by
default. (Or should it be enabled by default?)
svn path=/nixpkgs/branches/xorg-7.5/; revision=18019
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
