This makes things more efficient (we don't need to use an SSH master
connection, and we only start a single remote process) and gets rid of
locking issues (the remote nix-store process will keep inputs and
outputs locked as long as they're needed).

It also makes it more or less secure to connect directly to the root
account on the build machine, using a forced command
(e.g. ‘command="nix-store --serve --write"’). This bypasses the Nix
daemon and is therefore more efficient.

Also, don't call nix-store to import the output paths.

This causes nix-copy-closure to show what it's doing before rather
than after.

This means we no longer need an SSH master connection, since we only
execute a single command on the remote host.

C++11 lambdas ftw.

There is a long-standing race condition when copying a closure to a
remote machine, particularly affecting build-remote.pl: the client
first asks the remote machine which paths it already has, then copies
over the missing paths. If the garbage collector kicks in on the
remote machine between the first and second step, the already-present
paths may be deleted. The missing paths may then refer to deleted
paths, causing nix-copy-closure to fail. The client now performs both
steps using a single remote Nix call (using ‘nix-store --serve’),
locking all paths in the closure while querying.

I changed the --serve protocol a bit (getting rid of QueryCommand), so
this breaks the SSH substituter from older versions. But it was marked
experimental anyway.

Fixes #141.

Since it didn't check that the path received from the client is a
store path, the client could dump any path in the file system.

src/libexpr/primops.cc:42:8: error: looser throw specifier for 'virtual nix::InvalidPathError::~InvalidPathError()'
src/libexpr/nixexpr.hh:12:1: error:   overriding 'virtual nix::EvalError::~EvalError() noexcept (true)'

http://hydra.nixos.org/build/12385750

Its C++ compiler is too old.

http://hydra.nixos.org/build/12385722

Fixes #294.

Only add the importNative primop if the allow-arbitrary-code-during-evaluation option is true (default false)

This can be used to import a dynamic shared object and return an
arbitrary value, including new primops. This can be used both to test
new primops without having to recompile nix every time, and to build
specialized primops that probably don't belong upstream (e.g. a function
that calls out to gpg to decrypt a nixops secret as-needed).

The imported function should initialize the Value & as needed. A single
import can define multiple values by creating an attrset or list, of
course.

An example initialization function might look like:

extern "C" void initialize(nix::EvalState & state, nix::Value & v)
{
    v.type = nix::tPrimOp;
    v.primOp = NEW nix::PrimOp(myFun, 1, state.symbols.create("myFun"));
}

Then `builtins.importNative ./example.so "initialize"` will evaluate to
the primop defined in the myFun function.

They're a little bit too recent (only supported since GCC 4.7).

http://hydra.nixos.org/build/11851475

Also, yay for C++11 non-static initialisers.

We're not catching these anywhere.

In addition to reducing duplication, this fixes both import from
derivation and import of derivation for scopedImport

- Use define-derived-mode to declare nix-mode
- Use autoloads to ensure nix-mode is usable (and enabled) without needing `require`
- Use set + make-local-variable instead of longer 2-step equivalent

There really is no case I can think of where taking the context into
account is useful. Mostly it's just very inconvenient.

When copying a large path causes the daemon to run out of memory, you
now get:

  error: Nix daemon out of memory

instead of:

  error: writing to file: Broken pipe

I.e. if you have a derivation with

  src = ./huge-directory;

you'll get a warning that this is not a good idea.