Instead, figure out VERSION at build-time. This simplifies using
overrideDerivation (no need to copy and modify installPhase).
Also add a check that the file exists (catch potential failure early).
New build system using configure script and GNU Make 4.0, and new
releases of the following using the new build system:
execline 2.0.0.0
s6 2.0.0.0
s6-dns 2.0.0.0
s6-linux-utils 2.0.0.0
s6-networking 2.0.0.0
s6-portable-utils 2.0.0.0
skalibs 2.0.0.0
Cargo downloads your Rust project's dependencies and builds your
project.
The cargoSnapshot derivation simply uses a binary build, because
it's not easy to build cargo from source yet.
In the future, it's expected that we'll also add a derivation for
building cargo from source.
(My OCD kicked in today...)
Remove repeated package names, capitalize first word, remove trailing
periods and move overlong descriptions to longDescription.
I also simplified some descriptions as well, when they were particularly
long or technical, often based on Arch Linux' package descriptions.
I've tried to stay away from generated expressions (and I think I
succeeded).
Some specifics worth mentioning:
* cron, has "Vixie Cron" in its description. The "Vixie" part is not
mentioned anywhere else. I kept it in a parenthesis at the end of the
description.
* ctags description started with "Exuberant Ctags ...", and the
"exuberant" part is not mentioned elsewhere. Kept it in a parenthesis
at the end of description.
* nix has the description "The Nix Deployment System". Since that
doesn't really say much what it is/does (especially after removing
the package name!), I changed that to "Powerful package manager that
makes package management reliable and reproducible" (borrowed from
nixos.org).
* Tons of "GNU Foo, Foo is a [the important bits]" descriptions
is changed to just [the important bits]. If the package name doesn't
contain GNU I don't think it's needed to say it in the description
either.
This includes a lot of fixes for cross-building to Windows and Mac OS X
and could possibly fix things even for non-cross-builds, like for
example OpenSSL on Windows.
The main reason for merging this in 14.04 already is that we already
have runInWindowsVM in master and it doesn't work until we actually
cross-build Cygwin's setup binary as the upstream version is a fast
moving target which gets _overwritten_ on every new release.
Conflicts:
pkgs/top-level/all-packages.nix
Both branches have quite a lot in common, so it's time for a merge and
do the cleanups with respect to both implementations and also generalize
both implementations as much as possible.
This also closes#1876.
Conflicts:
pkgs/development/interpreters/lua-5/5.2.nix
pkgs/development/libraries/SDL/default.nix
pkgs/development/libraries/glew/default.nix
pkgs/top-level/all-packages.nix
For instance, a package can now say:
buildInputs = [ ant jre ecj ];
which would cause the Eclipse compiler to be used with the OpenJRE.
Similarly:
buildInputs = [ ant gcj ];
uses the GNU JVM with the GNU Java compiler.
Also, Ant no longer has a build-time dependency on a particular JDK.
It finds the JDK via $JAVA_HOME or $PATH (by looking up javac). This
way, we don't need to have separate packages like apacheAntOpenJDK and
apacheAntOracleJDK. It also seems reasonable: after all, installing
GNU Make doesn't give you a C compiler either. It does mean that
instead of
buildInputs = [ ant ];
you now need to write something like
buildInputs = [ ant jdk ];
* Remove package name
* Start with upper case letter
* Remove trailing period
Also reword some descriptions and move some long descriptions to
longDescription.
I'm not touching generated packages.
There are many more packages to fix, this is just a start.
Rules:
* Don't repeat the package name (not always that easy...)
* Start with capital letter
* Don't end with full stop
* Don't start with "The ..." or "A ..."
I've also added descriptions to some packages and rewritten others.
Unfortunately, leiningen will now pull in some dependencies via maven (via http) on `lein version' so the test at the end of builder.sh failed. This is okay because leiningen is used only as a interactive tool and no other package in Nixpkgs depends on it.
Signed-off-by: Moritz Ulrich <moritz@tarn-vedra.de>
This breaks some packages (notably liblapack) due to a broken macro
(CTEST_CUSTOM_POST_TEST). See NixOS/nixpkgs#762
This reverts commit ebc424c3ab.
Signed-off-by: Shea Levy <shea@shealevy.com>
The changelog is available at:
http://www.cmake.org/files/v2.8/CMakeChangeLog-2.8.11
I had to create a new patch from scratch, that's why it contains a lot
of differences. CMake developers has rewritten the files
(Modules/Platform/Linux.cmake and Modules/Platform/UnixPaths.cmake) to
comply to their coding style requirements and a lot of elements has
switched from upper to lower case.
Also, the previous patch partially consisted of commenting some
instructions mixed with line removals whereas mine is directlty
removing them in order to avoid useless evaluations and parsing in
resulting files.
Version 1.2.0 is way too old in order to build the latest chromium (29) version,
so let's get it up to date (especially because no other package is referencing
ninja, so it should be non-critical).
The dependency on unzip is not needed here, because GitHub also provides
archives in tar.gz format.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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
ninja is a build system written in C++ that just happens to use python
to build/install *itself*. It is not a "python package".
After this commit, ninja will be at pkgs.ninja instead of
pkgs.pythonPackages.ninja.
* 0.8.7p1 doesn't contain *.info documentation; use manpage
instead
* Update meta.description to not contain the package name (redundant)
* 0.8.7p1 only builds with python dateutil==1.5, so that has to be added
as well
Runtime tested with the buildbot slave that is added in the next commit.
"ant-<JDK name>".
* Remove openjdkDarwin/ecjDarwin/antDarwin attributes. Instead
the openjdk attribute refers to the Darwin package on Darwin.
svn path=/nixpkgs/trunk/; revision=34505
- apply patch (applied upstream) to assume rlwrap is present
- update expression to depend on rlwrap
- rebase the nix-specific patch to apply cleanly
svn path=/nixpkgs/trunk/; revision=34056
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
- The flag "--mandir" has no effect with setup.py. Instead, "--install-data"
must be used.
- Don't generate wrappers for trivial symlink aliases in bin.
- Prefer symlinks over hard-links.
- The dependencies of this expression don't need to be propagated.
svn path=/nixpkgs/trunk/; revision=25021
I've also set the 'platforms' attribute to ensure that Hydra actually
builds these packages. Thanks to Lluís Batlle i Rossell for pointing out
these mistakes.
svn path=/nixpkgs/trunk/; revision=21688
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
I fixed conflicts regarding the renaming 'kernel' -> 'linux' in all-packages.
Also a small conflict in all-packages about making openssl overridable.
And I some linux 2.6.31-zen kernel files also marked in conflict.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19438
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
- Before this changes, cflags and ldflags for the native and the cross compiler
got mixed. Not all the gcc-wrapper/gcc-cross-wrapper variables are
independant now, but enough, I think.
- Fixed the generic stdenv expression, which did a big mess on buildInputs and
buildNativeInputs. Now it distinguishes when there is a stdenvCross or not.
Maybe we should have a single stdenv and forget about the stdenvCross
adapter - this could end in a stdenv a bit complex, but simpler than the
generic stdenv + adapter.
- Added basic support in pkgconfig for cross-builds: a single PKG_CONFIG_PATH
now works for both the cross and the native compilers, but I think this
should work well for most cases I can think of.
- I tried to fix the guile expression to cross-biuld; guile is built, but not
its manual, so the derivation still fails. Guile requires patching to
cross-build, as far as I understnad.
- Made the glibcCross build to be done through the usage of a
gcc-cross-wrapper over the gcc-cross-stage-static, instead of using it
directly.
- Trying to make physfs (a neverball dependency) cross build.
- Updated the gcc expression to support building a cross compiler without getting
derivation variables mixed with those of the stdenvCross.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18534
