Age | Commit message (Collapse) | Author |
|
approach. This makes it much easier to add extra complexity in the
normaliser / realiser (e.g., build hooks, substitutes).
|
|
|
|
|
|
|
|
|
|
|
|
hack.
|
|
|
|
to be specified in configure (using `--with-system=SYSTEM').
|
|
Linux), so use setpgid().
|
|
* When a fast build wakes up a goal, try to start that goal in the
same iteration of the startBuild() loop of run(). Otherwise no job
might be started until the next job terminates.
|
|
(Though the `build-remote.pl' script has a gigantic race condition).
|
|
|
|
per-machine maximum number of parallel jobs on a remote machine.
|
|
|
|
in parallel. Hooks are more efficient: locks on output paths are
only acquired when the hook says that it is willing to accept a
build job. Hooks now work in two phases. First, they should first
tell Nix whether they are willing to accept a job. Nix guarantuees
that no two hooks will ever be in the first phase at the same time
(this simplifies the implementation of hooks, since they don't have
to perform locking (?)). Second, if they accept a job, they are
then responsible for building it (on the remote system), and copying
the result back. These can be run in parallel with other hooks and
locally executed jobs.
The implementation is a bit messy right now, though.
* The directory `distributed' shows a (hacky) example of a hook that
distributes build jobs over a set of machines listed in a
configuration file.
|
|
|
|
no limit).
* Add missing file to distribution.
|
|
|
|
distributing a build action to another machine. In particular, the
paths in the input closures, the output paths, and successor mapping
for sub-derivations.
|
|
|
|
parallel as possible (similar to GNU Make's `-j' switch). This is
useful on SMP systems, but it is especially useful for doing builds
on multiple machines. The idea is that a large derivation is
initiated on one master machine, which then distributes
sub-derivations to any number of slave machines. This should not
happen synchronously or in lock-step, so the master must be capable
of dealing with multiple parallel build jobs. We now have the
infrastructure to support this.
TODO: substitutes are currently broken.
|
|
* Ignore EINTR in reads and writes.
|
|
possible.
This test fails right now because this hasn't been implemented right
now. Yes, I'm doing Test-Driven Development! ;-)
|
|
* A test to verify that locking of output paths (caused by concurrent
invocations of Nix) works correctly.
|
|
|
|
|
|
environment variables.
* Started adding some automatic tests.
* Do a `make check' when building RPMs.
|
|
|
|
|
|
* Documented release procedures.
|
|
|
|
|
|
is specified.
|
|
|
|
Nix expressions.
To subscribe to a channel (needs to be done only once):
nix-channel --add \
http://catamaran.labs.cs.uu.nl/dist/nix/channels/nixpkgs-unstable
This just adds the given URL to ~/.nix-channels (which can also be
edited manually).
To update from all channels:
nix-channel --update
This fetches the latest expressions and pulls cache manifests. The
default Nix expression (~/.nix-defexpr) is made to point to the
conjunction of the expressions downloaded from all channels.
So to update all installed derivations in the current user
environment:
nix-channel --update
nix-env --upgrade '*'
If you are really courageous, you can put this in a cronjob or
something.
You can subscribe to multiple channels. It is not entirely clear
what happens when there are name clashes between derivations from
different channels. From nix-env/main.cc it appears that the one
with the lowest (highest?) hash will be used, which is pretty
meaningless.
|
|
unless `--disable-init-state' is passed to configure.
|
|
an expression.
|
|
environment variable. This is useful for passing authentication
information (it won't show up in `ps'). Hacky - nix-push should
abstract over the use of Curl.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
efficient by creating only a single symlink to entire directory
trees unless a collission occurs.
|
|
|
|
* Made the dependencies on bzip2 and the shell explicit.
|
|
print a nice backtrace of the stack, rather than vomiting a gigantic
(and useless) aterm on the screen. Example:
error: while evaluating file `.../pkgs/system/test.nix':
while evaluating attribute `subversion' at `.../pkgs/system/all-packages-generic.nix', line 533:
while evaluating function at `.../pkgs/applications/version-management/subversion/default.nix', line 1:
assertion failed at `.../pkgs/applications/version-management/subversion/default.nix', line 13
Since the Nix expression language is lazy, the trace may be
misleading. The purpose is to provide a hint as to the location of
the problem.
|
|
binding.
|