* Use stdenv.mkDerivation instead of composableDerivation.
stdenv.mkDerivation is the current coding standard and is easier to
read (IMHO).
* Remove the 'parportSupport' flag because it doesn't do anything.
(Parallel port support is still enabled.)
* Remove unneeded --disable-dependency-tracking flag to ./configure; our
default builder does that already.
* Fix documentation build. But it is still disabled (by default),
because texLive is such a big dependency. There is always the man
page.
* Update 'meta' attributes
Verified on OS X 10.9.2 to build and check, dependents build fine too.
@vcunat enabled doCheck as it works for him on x86_64-linux;
also did style nitpick modification, and changed platforms to .all
according to the homepage http://www.swig.org/compat.html
fetchpatch is fetchurl that determinizes the patch.
Some parts of generated patches change from time to time, e.g. see #1983 and
http://comments.gmane.org/gmane.linux.distributions.nixos/12815
Using fetchpatch should prevent the hash from changing.
Conflicts (auto-solved):
pkgs/development/libraries/haskell/gitit/default.nix
When using scan-build, you're often going to want to use it in the
context of a Nix expression with buildInputs, and the default wrapper
scripts will put things like include locations for those inputs
$NIX_CFLAGS_COMPILE. Thus, scan-build also needs to pass them to the
analyzer - while the link flags aren't relevant, the include flags are.
This is because the analyzer executable that gets run by scan-build is
*not* clang-wrapper, but the actual clang executable, so it doesn't
implicitly add such arguments. The build is two-stage - it runs the real
clang wrapper once, and then the analyzer once.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This massively upgrades the frama-c package to be far more useful,
including support for a lot more plugins, including Jessie.
Jessie unfortunately requires that its plugin is installed alongside
frama-c, so we install why2 (where it lives) along with frama-c now.
This increases the size, but makes it much more useful.
In the future, it may be possible to split out the build such that why2
is a separate expression and frama-c only installs the plugin, rather
than all of why2. However, right now this is fine.
Furthermore, why3 is now a dependency - the Jessie plugin can use
either, and defaults to Why3 now. Per the design, Frama-C can also go
from Why2->Why3 as well.
We also make Coq and Alt-Ergo dependencies, so that out-of-the-box users
get at least one SMT solver and a prover for support.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
