nixpkgs/pkgs/build-support/release/nix-build.nix

176 lines
5.2 KiB
Nix
Raw Normal View History

# This function builds and tests an Autoconf-style source tarball.
# The result can be installed normally in an environment (e.g., after
# making it available through a channel). If `doCoverageAnalysis' is
# true, it does an ordinary build from a source tarball, except that
# it turns on GCC's coverage analysis feature. It then runs `make
# check' and produces a coverage analysis report using `lcov'.
{ buildOutOfSourceTree ? false
, preConfigure ? null
, doCoverageAnalysis ? false
releaseTools: add {clang,coverity}Analysis tools 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>
2014-05-02 18:26:41 +00:00
, doClangAnalysis ? false
, doCoverityAnalysis ? false
, lcovFilter ? []
, lcovExtraTraceFiles ? []
, src, stdenv
, name ? if doCoverageAnalysis then "nix-coverage" else "nix-build"
, failureHook ? null
, prePhases ? []
, postPhases ? []
, buildInputs ? []
, preHook ? ""
, postHook ? ""
, ... } @ args:
releaseTools: add {clang,coverity}Analysis tools 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>
2014-05-02 18:26:41 +00:00
let
doingAnalysis = doCoverageAnalysis || doClangAnalysis || doCoverityAnalysis;
in
stdenv.mkDerivation (
{
# Also run a `make check'.
doCheck = true;
# When doing coverage analysis, we don't care about the result.
releaseTools: add {clang,coverity}Analysis tools 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>
2014-05-02 18:26:41 +00:00
dontInstall = doingAnalysis;
useTempPrefix = doingAnalysis;
showBuildStats = true;
finalPhase =
''
# Propagate the release name of the source tarball. This is
# to get nice package names in channels.
if test -e $origSrc/nix-support/hydra-release-name; then
cp $origSrc/nix-support/hydra-release-name $out/nix-support/hydra-release-name
fi
releaseTools: add {clang,coverity}Analysis tools 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>
2014-05-02 18:26:41 +00:00
# Package up Coverity analysis results
if [ ! -z "${toString doCoverityAnalysis}" ]; then
if [ -d "_coverity_$name/cov-int" ]; then
mkdir -p $out/tarballs
NAME=`cat $out/nix-support/hydra-release-name`
cd _coverity_$name
tar caf $out/tarballs/$NAME-coverity-int.xz cov-int
echo "file cov-build $out/tarballs/$NAME-coverity-int.xz" >> $out/nix-support/hydra-build-products
fi
fi
# Package up Clang analysis results
if [ ! -z "${toString doClangAnalysis}" ]; then
if [ ! -z "`ls _clang_analyze_$name`" ]; then
cd _clang_analyze_$name && mv * $out/analysis
else
mkdir -p $out/analysis
echo "No bugs found." >> $out/analysis/index.html
fi
echo "report analysis $out/analysis" >> $out/nix-support/hydra-build-products
fi
'';
failureHook = (stdenv.lib.optionalString (failureHook != null) failureHook) +
''
if test -n "$succeedOnFailure"; then
if test -n "$keepBuildDirectory"; then
KEEPBUILDDIR="$out/`basename $TMPDIR`"
header "Copying build directory to $KEEPBUILDDIR"
mkdir -p $KEEPBUILDDIR
cp -R "$TMPDIR/"* $KEEPBUILDDIR
stopNest
fi
fi
'';
}
// args //
{
name = name + (if src ? version then "-" + src.version else "");
postHook = ''
. ${./functions.sh}
origSrc=$src
src=$(findTarball $src)
${postHook}
'';
releaseTools: add {clang,coverity}Analysis tools 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>
2014-05-02 18:26:41 +00:00
preHook = ''
# Perform Coverity Analysis
if [ ! -z "${toString doCoverityAnalysis}" ]; then
shopt -s expand_aliases
mkdir _coverity_$name
alias make="cov-build --dir _coverity_$name/cov-int make"
fi
# Perform Clang Analysis
if [ ! -z "${toString doClangAnalysis}" ]; then
shopt -s expand_aliases
alias make="scan-build -o _clang_analyze_$name --html-title='Scan results for $name' make"
fi
${preHook}
releaseTools: add {clang,coverity}Analysis tools 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>
2014-05-02 18:26:41 +00:00
'';
# Clean up after analysis
postBuild = ''
if [ ! -z "${toString (doCoverityAnalysis || doClangAnalysis)}" ]; then
unalias make
fi
'';
initPhase = ''
mkdir -p $out/nix-support
echo "$system" > $out/nix-support/system
releaseTools: add {clang,coverity}Analysis tools 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>
2014-05-02 18:26:41 +00:00
if [ -z "${toString doingAnalysis}" ]; then
for i in $outputs; do
if [ "$i" = out ]; then j=none; else j="$i"; fi
mkdir -p ''${!i}/nix-support
echo "nix-build $j ''${!i}" >> ''${!i}/nix-support/hydra-build-products
done
fi
'';
prePhases = ["initPhase"] ++ prePhases;
releaseTools: add {clang,coverity}Analysis tools 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>
2014-05-02 18:26:41 +00:00
buildInputs =
buildInputs ++
(stdenv.lib.optional doCoverageAnalysis args.makeGCOVReport) ++
(stdenv.lib.optional doClangAnalysis args.clang-analyzer) ++
releaseTools: add {clang,coverity}Analysis tools 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>
2014-05-02 18:26:41 +00:00
(stdenv.lib.optional doCoverityAnalysis args.cov-build) ++
(stdenv.lib.optional doCoverityAnalysis args.xz);
lcovFilter = ["/nix/store/*"] ++ lcovFilter;
inherit lcovExtraTraceFiles;
postPhases = postPhases ++ ["finalPhase"];
meta = (if args ? meta then args.meta else {}) // {
description = if doCoverageAnalysis then "Coverage analysis" else "Nix package for ${stdenv.system}";
};
}
//
(if buildOutOfSourceTree
then {
preConfigure =
# Build out of source tree and make the source tree read-only. This
# helps catch violations of the GNU Coding Standards (info
# "(standards) Configuration"), like `make distcheck' does.
'' mkdir "../build"
cd "../build"
configureScript="../$sourceRoot/configure"
chmod -R a-w "../$sourceRoot"
echo "building out of source tree, from \`$PWD'..."
${if preConfigure != null then preConfigure else ""}
'';
}
else {})
)