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>
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
