| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
If derivation declares multiple outputs and first (default) output
if not "out", then "nix-instantiate" calls return path with output
names appended after "!". Than suffix must be stripped before
ant path checks are done.
|
|
|
|
This allows you to easily set up a build environment containing the
specified packages from Nixpkgs. For example:
$ nix-shell -p sqlite xorg.libX11 hello
will start a shell in which the given packages are present.
|
|
line
This is basically a shortcut for ‘echo 'expr...' | nix-instantiate -’.
Also supported by nix-build and nix-shell.
|
|
|
|
The flag ‘--check’ to ‘nix-store -r’ or ‘nix-build’ will cause Nix to
redo the build of a derivation whose output paths are already valid.
If the new output differs from the original output, an error is
printed. This makes it easier to test if a build is deterministic.
(Obviously this cannot catch all sources of non-determinism, but it
catches the most common one, namely the current time.)
For example:
$ nix-build '<nixpkgs>' -A patchelf
...
$ nix-build '<nixpkgs>' -A patchelf --check
error: derivation `/nix/store/1ipvxsdnbhl1rw6siz6x92s7sc8nwkkb-patchelf-0.6' may not be deterministic: hash mismatch in output `/nix/store/4pc1dmw5xkwmc6q3gdc9i5nbjl4dkjpp-patchelf-0.6.drv'
The --check build fails if not all outputs are valid. Thus the first
call to nix-build is necessary to ensure that all outputs are valid.
The current outputs are left untouched: the new outputs are either put
in a chroot or diverted to a different location in the store using
hash rewriting.
|
|
Since normal builds don't execute shellHook, this allows nix-shell
specific customisation. Suggested by Domen.
|
|
|
|
This is currently the default, but I might change that to --pure in
the future.
|
|
|
|
|
|
It generally is not useful in interactive environments (and messes up
some non-ANSI-compliant terminals).
|
|
|
|
This reverts commit 0c1198cf08576f16633b2344dc6513cefb567cfc.
|
|
Signed-off-by: Shea Levy <shea@shealevy.com>
|
|
|
|
This has some hacky applications.
|
|
Fixes #181.
|
|
|
|
Shouldn't really matter, but you never know.
|
|
nix-shell with the --command flag might be used non-interactively, but
if bash starts non-interactively (i.e. with stdin or stderr not a
terminal), it won't source the script given in --rcfile. However, in
that case it *will* source the script found in $BASH_ENV, so we can use
that instead.
Also, don't source ~/.bashrc in a non-interactive shell (detectable by
checking the PS1 env var)
Signed-off-by: Shea Levy <shea@shealevy.com>
|
|
Nixpkgs's stdenv setup script sets the "nullglob" option, but doing so
breaks Bash completion on NixOS (when ‘programs.bash.enableCompletion’
is set) and on Ubuntu. So clear that flag afterwards. Of course,
this may break stdenv functions in subtle ways...
|
|
Fixes #161.
|
|
Nixpkgs' stdenv disables dependency tracking by default. That makes
sense for one-time builds, but in an interactive environment we expect
repeated "make" invocations to do the right thing.
|
|
This allows scripts to distinguish between a real build and a Nix
shell.
|
|
Setting $NIX_STORE causes the purity checks in gcc/ld-wrapper to kick
in, so that's why we unset $NIX_ENFORCE_PURITY.
|
|
|
|
This causes the environment to be (almost) cleared, thus giving a
shell that more closely resembled the actual Nix derivation.
|
|
Fixes #113.
Fixes #131.
|
|
This ensures that not just environment variables are set, but also
shell functions such as unpackPhase, configurePhase and so on.
|
|
|
|
|
|
For example, given a derivation with outputs "out", "man" and "bin":
$ nix-build -A pkg
produces ./result pointing to the "out" output;
$ nix-build -A pkg.man
produces ./result-man pointing to the "man" output;
$ nix-build -A pkg.all
produces ./result, ./result-man and ./result-bin;
$ nix-build -A pkg.all -A pkg2
produces ./result, ./result-man, ./result-bin and ./result-2.
|
|
I.e. do what git does. I'm too lazy to keep the builtin help text up
to date :-)
Also add ‘--help’ to various commands that lacked it
(e.g. nix-collect-garbage).
|
|
|
|
|
|
Output names are now appended to resulting GC symlinks, e.g. by
nix-build. For backwards compatibility, if the output is named "out",
nothing is appended. E.g. doing "nix-build -A foo" on a derivation
that produces outputs "out", "bin" and "dev" will produce symlinks
"./result", "./result-bin" and "./result-dev", respectively.
|
|
|
|
|
|
|
|
|
|
|
|
Sometimes when doing "nix-build --run-env" you don't want all
dependencies to be built. For instance, if we want to do "--run-env"
on the "build" attribute in Hydra's release.nix (to get Hydra's build
environment), we don't want its "tarball" dependency to be built. So
we can do:
$ nix-build --run-env release.nix -A build --exclude 'hydra-tarball'
This will skip the dependency whose name matches the "hydra-tarball"
regular expression. The "--exclude" option can be repeated any number
of times.
|
|
--command
|
|
This command builds or fetches all dependencies of the given
derivation, then starts a shell with the environment variables from
the derivation. This shell also sources $stdenv/setup to initialise
the environment further.
The current directory is not changed. Thus this is a convenient way
to reproduce a build environment in an existing working tree.
Existing environment variables are left untouched (unless the
derivation overrides them). As a special hack, the original value of
$PATH is appended to the $PATH produced by $stdenv/setup.
Example session:
$ nix-build --run-env '<nixpkgs>' -A xterm
(the dependencies of xterm are built/fetched...)
$ tar xf $src
$ ./configure
$ make
$ emacs
(... hack source ...)
$ make
$ ./xterm
|
|
directory rather than the current directory.
* nix-build: --drv-link now implies --add-drv-link.
|
|
scripts.
* Include the version and architecture in the -I flag so that there is
at least a chance that a Nix binary built for one Perl version will
run on another version.
|
|
|
|
|
