These two expressions greatly simplify using the clang-analyzer or
Coverity static analyzer on your C/C++ projects. In fact, they are
identical to nixBuild in every way out of the box, and should 'Just
Work' providing your code can be compiled with Clang already.
The trick is that when running 'make', we actually just alias it to the
appropriate scan build tool, and add a post-build hook that will bundle
up the results appropriately and unalias it.
For Clang, we put the results in $out/analysis and add an 'analysis'
report to $out/nix-support/hydra-build-products pointing to the result
HTML - this means that if the analyzer finds any bugs, the HTML results
will automatically show up Hydra for easy viewing.
For Coverity, it's slightly different. Instead we run the build tool and
after we're done, we tar up the results in a format that Coverity Scan's
service understands. We put the tarball in $out/tarballs under the name
'foo-cov-int.xz' and add an entry for the file to hydra-build-products
as well for easy viewing.
Of course for Coverity you must then upload the build. A Hydra plugin to
do this is on the way, and it will automatically pick up the
cov-int.tar.xz for uploading.
Note that coverityAnalysis requires allowUnfree = true;, as well as the
cov-build tools, which you can download from https://scan.coverity.com -
they're not linked to your account or anything, it's just an annoying
registration wall.
Note this is a first draft. In particular, scan-build fixes the C/C++
compiler to be Clang, and it's perfectly reasonable to want to use Clang
for the analyzer but have scan-build invoke GCC instead.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Stdenv adapters are kinda weird and un-idiomatic (especially when they
don't actually change stdenv). It's more idiomatic to say
buildInputs = [ makeCoverageAnalysisReport ];
extension postHook) does nothing else than set up the environment.
It shouldn't touch $out because there may not be a $out. So move
the "imperative" bits of postHook into a separate phase.
svn path=/nixpkgs/trunk/; revision=33249
* Added a function binaryTarball to do a DESTDIR build into
/usr/local. Useful for making statically linked binaries. However,
it may be better to do this in a VM (since if you do it in a Nix
build environment, you can still end up with a lot of Nix
dependencies in your binaries, even if you do static linking).
svn path=/nixpkgs/trunk/; revision=14726
of Hydra builds more distinct (e.g. "patchelf-build-0.5pre1234"
instead of just "patchelf-build"). If the version isn't known,
append at least the revision.
* Propagate the release name of the source tarball to Nix builds.
Useful to provide sensible package names in channels.
svn path=/nixpkgs/trunk/; revision=14294
(e.g. making source tarballs, doing coverage analysis) to the
Nixpkgs tree. This makes it easier to run build farm jobs locally
since you don't need to check out the "release" tree separately.
Also it means one less input to declare for build farm jobs.
* Removed succeedOnFailure and separate logging of phases. Hydra
doesn't need that.
svn path=/nixpkgs/trunk/; revision=13388
