| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
|
| |
|
|
| |
It is deprecated and will be removed after 18.09.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
releaseTools: add channel function
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
| |
override them
|
| |
|
|
|
|
| |
Fixes https://github.com/NixOS/nixpkgs/issues/10931.
antBuild overrides buildPhase and installPhase without calling default
hooks.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Checkinstall had two problems:
1. when it was called without a version (e.g. with a derivation created
by fetchFromGitHub) it would use `src` as debian version, which caused
dpkg to fail
2. when dpkg failed, it would invoke the pager with the log, which hangs
the build
So now
1. the default version is the dummy `0.0.0`
2. the used pager is `cat`
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
http://hydra.nixos.org/build/17037187
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It was failing because the bash subshell died with SIGPIPE, which is
no longer ignored.
http://hydra.nixos.org/build/16766452
|
| | |
|
| | |
|
| |
|
|
| |
byte-for-byte identical jars (they normally contain timestamps and nondeterministic ordering of metadata lines)
|
| |\ |
|
| | |
| |
| |
| | |
See c556a6ea46e71e1907d78b71fab36df30297b3ad.
|
| |/ |
|
| |
|
|
| |
prevent unnecessary compilation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
Also, turn some stdenv adapters into setup hooks.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Stdenv adapters are kinda weird and un-idiomatic (especially when they
don't actually change stdenv). It's more idiomatic to say
buildInputs = [ makeCoverageAnalysisReport ];
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
They're so trivial that we don't want to copy all those dependencies
to remote machines.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An aggregate is a trivial build that depends on other builds. This is
intended to provide a declarative replacement of Hydra's "view"
mechanism.
For instance, you can define an aggregate named "critical" that
depends on a selected set of jobs:
critical = releaseTools.aggregate
{ name = "foo-${tarball.version}";
members =
[ tarball
build.x86_64-linux
...
];
meta.description = "Release-critical builds";
};
The "critical" build will only succeed if all its members
(dependencies) succeed.
|
| | |
|
| |
|
|
|
| |
Phrases like "Build of a ..." are redundant because everything is a
build.
|
| |
|
|
|
| |
Putting a single hydra-build-products in $out can cause $out to have
unnecessary dependencies on other outputs.
|
| | |
|
| | |
|
| | |
|
| | |
|