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
* 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
The initial MacOS X binaries have been linked to libgmp.dylib using some
mad path in /opt that's now hard-coded into the program. Consequently,
$DYLD_LIBRARY_PATH must contain the place where libgmp really is for
those binaries to run correctly. Tested on i386-apple-darwin9.7.0.
svn path=/nixpkgs/trunk/; revision=17873
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
so all hooks on PERL5LIB include this module properly.
I don't know why this doesn't install the files to that */site_perl/* by default.
svn path=/nixpkgs/trunk/; revision=17837
I don't know if the 'unfree' in the amr libraries will stop mplayer being built without its support. We would have to write the all-packages MPlayer expression different, in this case.
svn path=/nixpkgs/trunk/; revision=17635
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/FCC can do that, but the gcc from Nix can't.
The solution is to compile Perl 5.10 via Nix so that it can properly configure
itself. However, note that the resulting binary is impure: it will find headers
in /usr/include and libraries in /usr/lib -- something a pure perl binary
wouldn't do. In this respect our Nix-compiled perl binary is not better than
the native one from /usr/bin -- it's just more accurately configured.
svn path=/nixpkgs/trunk/; revision=17618
They removed the usual tagged library names in 1.40 under the layout
"system", but they introduced a new layout "tagged". The "tagged" layout
is needed when we want more than one 'style' of the libraries at once(debug,release, ...
svn path=/nixpkgs/trunk/; revision=17585
* Dropped classr.patch; it no longer applies to this version.
* The "configure" script has been renamed to "bootstrap.sh".
* The bootstrapping process generates no Makefile anymore; the build
expression has to call bjam directly to build the libraries.
* Perform build and install phase in one execution of bjam. This is a
lot faster, because bjam won't check the dependencies twice.
svn path=/nixpkgs/trunk/; revision=17471
$out/share/PolicyKit/policy - otherwise we can't let PolicyKit find
the policies of other packages (such as HAL).
svn path=/nixpkgs/trunk/; revision=17438
configure script prints out this ominous warning:
WARNING: PolicyKit is disabled. You need to manually edit the hal.conf
file to lock down the service. Failure to do so allows any
caller to make hald do work on their behalf which may be
a huge SECURITY HOLE. I repeat: YOU NEED TO EDIT THE FILE
hal.conf to match your distro/site to avoid NASTY SECURITY HOLES.
Note that HAL only builds with the old PolicyKit (it looks for
polkit.pc). Reverted ConsoleKit to the last version that used the
old PolicyKit for this reason.
svn path=/nixpkgs/trunk/; revision=17432
a headache. "polkit" is the new, unstable release series.
"policykit" is the old series. (See
http://lists.freedesktop.org/archives/polkit-devel/2009-February/000106.html
for an "explanation" of the name change.) It seems that for HAL we
need to revert to the old "policykit", since it doesn't compile
against "polkit".
svn path=/nixpkgs/trunk/; revision=17425
