set CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH based on NIX_CFLAGS_COMPILE and
NIX_LDFLAGS so that cmake's find_library like functions find all the libraries
gcc knows about thanks to the gcc wrapper
This is particular useful with myEnvFun which then also sets those CMAKE_* env
variables.`
Because setup.sh has to change this causes many rebuilds - thus it should be
included in a stdenv-update like branch
Also cmake builds in parallel perfectly fine
update cmake to latest minor number, I didn't change the patches,
just reapplied them manually recordin a new patch
projects to be built in Release by default.
Some packages were not getting optimisation flags, like rigsofrods.
svn path=/nixpkgs/branches/stdenv-updates/; revision=32574
Not merged r32497 (tree conflict, glibc GNU Hurd update). Ludovic, could you
please look at this?
svn path=/nixpkgs/branches/stdenv-updates/; revision=32520
This is the minimum version required for KDE-4, so I need it to ensure that my
cmake code works with cmake-2.6.4.
svn path=/nixpkgs/trunk/; revision=32504
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
looking in /usr and similar locations. However, it *will* now look
in the Nixpkgs Glibc lib and include directories. This ensures that
find_library can find libraries in Glibc.
svn path=/nixpkgs/branches/kde-4.7/; revision=27884
That way, we don't need the patch anymore to fix what that part broke.
Also kde stops needing the findqt4 patch (for its own copy of the findqt4 cmake module).
I tested a nixos-rebuild with kde4, and it builds as far as hydra built with this configuration.
svn path=/nixpkgs/trunk/; revision=20921
I updated cmake to use CMAKE_PREFIX_PATH instead of CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH.
There were some expressions in kde that required CMAKE_PREFIX_PATH, and now they are not anymore
a special case.
I updated most kde-4.4 files to point to kde-4.4.0 sources instead of 4.3.4 .
svn path=/nixpkgs/trunk/; revision=19965
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
