(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.
It's to separate from other changes coming from master.
Conflicts:
pkgs/development/libraries/glibc/2.18/common.nix (taking both changes)
pkgs/development/libraries/ncurses/5_4.nix (deleted)
We already have backward compatibility symlinks for ncurses libraries
and pkg-config files (when built in unicode/wide mode). The last bit is
to add a symlink from ncurses5-config to ncursesw5-config, which is what
this commit does.
To make e.g. "pkg-config --cflags ncursesw" work.
The ncurses expression, when built in unicode/wide char mode, provides
backward compatibility symlinks from lib<name>.so to lib<name>w.so.
Provide similar symlinks for the *.pc files: <name>.pc -> <name>w.pc.
${out} in configureFlags isn't expanded, so ncursesw5-config ends up
expanding ${out} at *runtime*. Here is the relevant ncursesw5-config
snippet showing how includedir gets its value at runtime.
bindir="${exec_prefix}/bin"
includedir="${out}/include"
libdir="${exec_prefix}/lib"
datadir="${prefix}/share"
mandir="${prefix}/man"
When running in a plain shell you get this:
$ ncursesw5-config --cflags
-I/include/ncursesw -I/include
And when run in a nix-build shell for e.g. gpsd:
$ ncursesw5-config --cflags
-I/nix/store/HASH-gpsd-3.10/include/ncursesw -I/nix/store/HASH-gpsd-3.10/include
This is clearly wrong.
Q: How come this has gone undetected for years?
A: It seems few packages use ncursesw5-config to get the compiler
flags. For example, our python curses module builds its own compiler
flags.
Fix this by moving the --includedir setting to preConfigure where shell
variables are expanded.
This is needed for the ncurses cabal package to compile. It uses
include/ncursesw/curses.h, without trying include/curses.h first. The
files are provided through include/ncursesw on a clean Debian too, in
the unicode case (when the libncursesw5-dev is installed).
Signed-off-by: Domen Kozar <domen@dev.si>
- Disabling guile test, because one fails. I commented on that in the source.
On cross builds:
- Adding stripping
- Updating the glibc-2.11 expression to match the parameters of glibc-2.9,
which I was updating more.
- Renaming from selfNativeBuildInput to selfBuildNativeInput, so this matches
better the pattern buildNativeInputs.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18550
true/false, which tells whether the derivation needs itself as
buildNativeInput.
For example, in order to build cross ncurses, we need the a native build
ncurses.
(As libtool does not work in stdenv, I have not tested this change, to check
whether finally ncurses cross-build)
svn path=/nixpkgs/branches/stdenv-updates/; revision=18489