2012-07-18 18:59:03 +00:00
|
|
|
#pragma once
|
2003-06-16 13:33:38 +00:00
|
|
|
|
2020-03-21 15:07:16 +00:00
|
|
|
#include "path.hh"
|
2010-05-12 22:13:09 +00:00
|
|
|
#include "types.hh"
|
2011-07-20 18:10:47 +00:00
|
|
|
#include "hash.hh"
|
2020-06-02 19:44:58 +00:00
|
|
|
#include "content-address.hh"
|
2010-05-12 22:13:09 +00:00
|
|
|
|
2012-09-11 18:45:42 +00:00
|
|
|
#include <map>
|
2020-03-19 04:37:57 +00:00
|
|
|
#include <variant>
|
2012-09-11 18:45:42 +00:00
|
|
|
|
2006-09-04 21:06:23 +00:00
|
|
|
|
|
|
|
namespace nix {
|
2003-06-16 13:33:38 +00:00
|
|
|
|
|
|
|
|
2005-01-19 14:36:00 +00:00
|
|
|
/* Abstract syntax of derivations. */
|
* Removed the `id' attribute hack.
* Formalise the notion of fixed-output derivations, i.e., derivations
for which a cryptographic hash of the output is known in advance.
Changes to such derivations should not propagate upwards through the
dependency graph. Previously this was done by specifying the hash
component of the output path through the `id' attribute, but this is
insecure since you can lie about it (i.e., you can specify any hash
and then produce a completely different output). Now the
responsibility for checking the output is moved from the builder to
Nix itself.
A fixed-output derivation can be created by specifying the
`outputHash' and `outputHashAlgo' attributes, the latter taking
values `md5', `sha1', and `sha256', and the former specifying the
actual hash in hexadecimal or in base-32 (auto-detected by looking
at the length of the attribute value). MD5 is included for
compatibility but should be considered deprecated.
* Removed the `drvPath' pseudo-attribute in derivation results. It's
no longer necessary.
* Cleaned up the support for multiple output paths in derivation store
expressions. Each output now has a unique identifier (e.g., `out',
`devel', `docs'). Previously there was no way to tell output paths
apart at the store expression level.
* `nix-hash' now has a flag `--base32' to specify that the hash should
be printed in base-32 notation.
* `fetchurl' accepts parameters `sha256' and `sha1' in addition to
`md5'.
* `nix-prefetch-url' now prints out a SHA-1 hash in base-32. (TODO: a
flag to specify the hash.)
2005-01-17 16:55:19 +00:00
|
|
|
|
2020-08-05 14:44:39 +00:00
|
|
|
/* The traditional non-fixed-output derivation type. */
|
2020-07-12 15:56:20 +00:00
|
|
|
struct DerivationOutputInputAddressed
|
* Removed the `id' attribute hack.
* Formalise the notion of fixed-output derivations, i.e., derivations
for which a cryptographic hash of the output is known in advance.
Changes to such derivations should not propagate upwards through the
dependency graph. Previously this was done by specifying the hash
component of the output path through the `id' attribute, but this is
insecure since you can lie about it (i.e., you can specify any hash
and then produce a completely different output). Now the
responsibility for checking the output is moved from the builder to
Nix itself.
A fixed-output derivation can be created by specifying the
`outputHash' and `outputHashAlgo' attributes, the latter taking
values `md5', `sha1', and `sha256', and the former specifying the
actual hash in hexadecimal or in base-32 (auto-detected by looking
at the length of the attribute value). MD5 is included for
compatibility but should be considered deprecated.
* Removed the `drvPath' pseudo-attribute in derivation results. It's
no longer necessary.
* Cleaned up the support for multiple output paths in derivation store
expressions. Each output now has a unique identifier (e.g., `out',
`devel', `docs'). Previously there was no way to tell output paths
apart at the store expression level.
* `nix-hash' now has a flag `--base32' to specify that the hash should
be printed in base-32 notation.
* `fetchurl' accepts parameters `sha256' and `sha1' in addition to
`md5'.
* `nix-prefetch-url' now prints out a SHA-1 hash in base-32. (TODO: a
flag to specify the hash.)
2005-01-17 16:55:19 +00:00
|
|
|
{
|
2020-07-12 16:12:21 +00:00
|
|
|
/* Will need to become `std::optional<StorePath>` once input-addressed
|
|
|
|
derivations are allowed to depend on cont-addressed derivations */
|
2019-12-05 18:11:09 +00:00
|
|
|
StorePath path;
|
2020-07-08 23:11:39 +00:00
|
|
|
};
|
|
|
|
|
2020-08-05 14:44:39 +00:00
|
|
|
/* Fixed-output derivations, whose output paths are content addressed
|
|
|
|
according to that fixed output. */
|
|
|
|
struct DerivationOutputCAFixed
|
2020-07-08 23:11:39 +00:00
|
|
|
{
|
|
|
|
FixedOutputHash hash; /* hash used for expected hash computation */
|
2020-08-07 19:09:26 +00:00
|
|
|
StorePath path(const Store & store, std::string_view drvName, std::string_view outputName) const;
|
2020-07-08 23:11:39 +00:00
|
|
|
};
|
|
|
|
|
2020-08-05 14:44:39 +00:00
|
|
|
/* Floating-output derivations, whose output paths are content addressed, but
|
|
|
|
not fixed, and so are dynamically calculated from whatever the output ends
|
|
|
|
up being. */
|
|
|
|
struct DerivationOutputCAFloating
|
2020-07-12 16:12:21 +00:00
|
|
|
{
|
|
|
|
/* information used for expected hash computation */
|
|
|
|
FileIngestionMethod method;
|
|
|
|
HashType hashType;
|
|
|
|
};
|
|
|
|
|
2020-07-08 23:11:39 +00:00
|
|
|
struct DerivationOutput
|
|
|
|
{
|
2020-07-12 16:12:21 +00:00
|
|
|
std::variant<
|
|
|
|
DerivationOutputInputAddressed,
|
2020-08-05 14:44:39 +00:00
|
|
|
DerivationOutputCAFixed,
|
|
|
|
DerivationOutputCAFloating
|
2020-07-12 16:12:21 +00:00
|
|
|
> output;
|
2020-07-12 16:12:21 +00:00
|
|
|
std::optional<HashType> hashAlgoOpt(const Store & store) const;
|
2020-07-27 20:42:02 +00:00
|
|
|
/* Note, when you use this function you should make sure that you're passing
|
|
|
|
the right derivation name. When in doubt, you should use the safer
|
2020-08-14 17:00:13 +00:00
|
|
|
interface provided by BasicDerivation::outputsAndOptPaths */
|
2020-09-15 15:21:39 +00:00
|
|
|
std::optional<StorePath> path(const Store & store, std::string_view drvName, std::string_view outputName) const;
|
* Removed the `id' attribute hack.
* Formalise the notion of fixed-output derivations, i.e., derivations
for which a cryptographic hash of the output is known in advance.
Changes to such derivations should not propagate upwards through the
dependency graph. Previously this was done by specifying the hash
component of the output path through the `id' attribute, but this is
insecure since you can lie about it (i.e., you can specify any hash
and then produce a completely different output). Now the
responsibility for checking the output is moved from the builder to
Nix itself.
A fixed-output derivation can be created by specifying the
`outputHash' and `outputHashAlgo' attributes, the latter taking
values `md5', `sha1', and `sha256', and the former specifying the
actual hash in hexadecimal or in base-32 (auto-detected by looking
at the length of the attribute value). MD5 is included for
compatibility but should be considered deprecated.
* Removed the `drvPath' pseudo-attribute in derivation results. It's
no longer necessary.
* Cleaned up the support for multiple output paths in derivation store
expressions. Each output now has a unique identifier (e.g., `out',
`devel', `docs'). Previously there was no way to tell output paths
apart at the store expression level.
* `nix-hash' now has a flag `--base32' to specify that the hash should
be printed in base-32 notation.
* `fetchurl' accepts parameters `sha256' and `sha1' in addition to
`md5'.
* `nix-prefetch-url' now prints out a SHA-1 hash in base-32. (TODO: a
flag to specify the hash.)
2005-01-17 16:55:19 +00:00
|
|
|
};
|
|
|
|
|
2006-09-04 21:06:23 +00:00
|
|
|
typedef std::map<string, DerivationOutput> DerivationOutputs;
|
2005-01-20 14:10:19 +00:00
|
|
|
|
2020-07-27 20:42:02 +00:00
|
|
|
/* These are analogues to the previous DerivationOutputs data type, but they
|
|
|
|
also contains, for each output, the (optional) store path in which it would
|
|
|
|
be written. To calculate values of these types, see the corresponding
|
|
|
|
functions in BasicDerivation */
|
|
|
|
typedef std::map<string, std::pair<DerivationOutput, StorePath>>
|
|
|
|
DerivationOutputsAndPaths;
|
|
|
|
typedef std::map<string, std::pair<DerivationOutput, std::optional<StorePath>>>
|
|
|
|
DerivationOutputsAndOptPaths;
|
|
|
|
|
2005-01-20 14:10:19 +00:00
|
|
|
/* For inputs that are sub-derivations, we specify exactly which
|
|
|
|
output IDs we are interested in. */
|
2019-12-05 18:11:09 +00:00
|
|
|
typedef std::map<StorePath, StringSet> DerivationInputs;
|
2005-01-20 14:10:19 +00:00
|
|
|
|
2006-09-04 21:06:23 +00:00
|
|
|
typedef std::map<string, string> StringPairs;
|
2003-07-20 19:29:38 +00:00
|
|
|
|
2020-06-03 17:38:54 +00:00
|
|
|
enum struct DerivationType : uint8_t {
|
2020-08-05 14:45:56 +00:00
|
|
|
InputAddressed,
|
2020-06-03 17:38:54 +00:00
|
|
|
CAFixed,
|
2020-07-17 19:55:41 +00:00
|
|
|
CAFloating,
|
2020-03-15 06:23:17 +00:00
|
|
|
};
|
|
|
|
|
2020-06-03 17:38:54 +00:00
|
|
|
/* Do the outputs of the derivation have paths calculated from their content,
|
|
|
|
or from the derivation itself? */
|
|
|
|
bool derivationIsCA(DerivationType);
|
|
|
|
|
|
|
|
/* Is the content of the outputs fixed a-priori via a hash? Never true for
|
|
|
|
non-CA derivations. */
|
|
|
|
bool derivationIsFixed(DerivationType);
|
|
|
|
|
|
|
|
/* Is the derivation impure and needs to access non-deterministic resources, or
|
|
|
|
pure and can be sandboxed? Note that whether or not we actually sandbox the
|
|
|
|
derivation is controlled separately. Never true for non-CA derivations. */
|
|
|
|
bool derivationIsImpure(DerivationType);
|
|
|
|
|
Allow remote builds without sending the derivation closure
Previously, to build a derivation remotely, we had to copy the entire
closure of the .drv file to the remote machine, even though we only
need the top-level derivation. This is very wasteful: the closure can
contain thousands of store paths, and in some Hydra use cases, include
source paths that are very large (e.g. Git/Mercurial checkouts).
So now there is a new operation, StoreAPI::buildDerivation(), that
performs a build from an in-memory representation of a derivation
(BasicDerivation) rather than from a on-disk .drv file. The only files
that need to be in the Nix store are the sources of the derivation
(drv.inputSrcs), and the needed output paths of the dependencies (as
described by drv.inputDrvs). "nix-store --serve" exposes this
interface.
Note that this is a privileged operation, because you can construct a
derivation that builds any store path whatsoever. Fixing this will
require changing the hashing scheme (i.e., the output paths should be
computed from the other fields in BasicDerivation, allowing them to be
verified without access to other derivations). However, this would be
quite nice because it would allow .drv-free building (e.g. "nix-env
-i" wouldn't have to write any .drv files to disk).
Fixes #173.
2015-07-17 15:57:40 +00:00
|
|
|
struct BasicDerivation
|
2003-07-20 19:29:38 +00:00
|
|
|
{
|
* Removed the `id' attribute hack.
* Formalise the notion of fixed-output derivations, i.e., derivations
for which a cryptographic hash of the output is known in advance.
Changes to such derivations should not propagate upwards through the
dependency graph. Previously this was done by specifying the hash
component of the output path through the `id' attribute, but this is
insecure since you can lie about it (i.e., you can specify any hash
and then produce a completely different output). Now the
responsibility for checking the output is moved from the builder to
Nix itself.
A fixed-output derivation can be created by specifying the
`outputHash' and `outputHashAlgo' attributes, the latter taking
values `md5', `sha1', and `sha256', and the former specifying the
actual hash in hexadecimal or in base-32 (auto-detected by looking
at the length of the attribute value). MD5 is included for
compatibility but should be considered deprecated.
* Removed the `drvPath' pseudo-attribute in derivation results. It's
no longer necessary.
* Cleaned up the support for multiple output paths in derivation store
expressions. Each output now has a unique identifier (e.g., `out',
`devel', `docs'). Previously there was no way to tell output paths
apart at the store expression level.
* `nix-hash' now has a flag `--base32' to specify that the hash should
be printed in base-32 notation.
* `fetchurl' accepts parameters `sha256' and `sha1' in addition to
`md5'.
* `nix-prefetch-url' now prints out a SHA-1 hash in base-32. (TODO: a
flag to specify the hash.)
2005-01-17 16:55:19 +00:00
|
|
|
DerivationOutputs outputs; /* keyed on symbolic IDs */
|
2019-12-05 18:11:09 +00:00
|
|
|
StorePathSet inputSrcs; /* inputs that are sources */
|
2003-07-20 19:29:38 +00:00
|
|
|
string platform;
|
2003-10-08 15:06:59 +00:00
|
|
|
Path builder;
|
2003-08-15 12:32:37 +00:00
|
|
|
Strings args;
|
2003-07-20 19:29:38 +00:00
|
|
|
StringPairs env;
|
2020-07-12 15:02:36 +00:00
|
|
|
std::string name;
|
Allow remote builds without sending the derivation closure
Previously, to build a derivation remotely, we had to copy the entire
closure of the .drv file to the remote machine, even though we only
need the top-level derivation. This is very wasteful: the closure can
contain thousands of store paths, and in some Hydra use cases, include
source paths that are very large (e.g. Git/Mercurial checkouts).
So now there is a new operation, StoreAPI::buildDerivation(), that
performs a build from an in-memory representation of a derivation
(BasicDerivation) rather than from a on-disk .drv file. The only files
that need to be in the Nix store are the sources of the derivation
(drv.inputSrcs), and the needed output paths of the dependencies (as
described by drv.inputDrvs). "nix-store --serve" exposes this
interface.
Note that this is a privileged operation, because you can construct a
derivation that builds any store path whatsoever. Fixing this will
require changing the hashing scheme (i.e., the output paths should be
computed from the other fields in BasicDerivation, allowing them to be
verified without access to other derivations). However, this would be
quite nice because it would allow .drv-free building (e.g. "nix-env
-i" wouldn't have to write any .drv files to disk).
Fixes #173.
2015-07-17 15:57:40 +00:00
|
|
|
|
2019-12-05 18:11:09 +00:00
|
|
|
BasicDerivation() { }
|
Allow remote builds without sending the derivation closure
Previously, to build a derivation remotely, we had to copy the entire
closure of the .drv file to the remote machine, even though we only
need the top-level derivation. This is very wasteful: the closure can
contain thousands of store paths, and in some Hydra use cases, include
source paths that are very large (e.g. Git/Mercurial checkouts).
So now there is a new operation, StoreAPI::buildDerivation(), that
performs a build from an in-memory representation of a derivation
(BasicDerivation) rather than from a on-disk .drv file. The only files
that need to be in the Nix store are the sources of the derivation
(drv.inputSrcs), and the needed output paths of the dependencies (as
described by drv.inputDrvs). "nix-store --serve" exposes this
interface.
Note that this is a privileged operation, because you can construct a
derivation that builds any store path whatsoever. Fixing this will
require changing the hashing scheme (i.e., the output paths should be
computed from the other fields in BasicDerivation, allowing them to be
verified without access to other derivations). However, this would be
quite nice because it would allow .drv-free building (e.g. "nix-env
-i" wouldn't have to write any .drv files to disk).
Fixes #173.
2015-07-17 15:57:40 +00:00
|
|
|
virtual ~BasicDerivation() { };
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
|
|
|
|
bool isBuiltin() const;
|
|
|
|
|
|
|
|
/* Return true iff this is a fixed-output derivation. */
|
2020-03-15 06:23:17 +00:00
|
|
|
DerivationType type() const;
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
|
2020-06-12 10:46:33 +00:00
|
|
|
/* Return the output names of a derivation. */
|
|
|
|
StringSet outputNames() const;
|
2020-07-12 15:26:30 +00:00
|
|
|
|
2020-07-27 20:42:02 +00:00
|
|
|
/* Calculates the maps that contains all the DerivationOutputs, but
|
2020-08-14 17:00:13 +00:00
|
|
|
augmented with knowledge of the Store paths they would be written
|
|
|
|
into. */
|
2020-07-27 20:42:02 +00:00
|
|
|
DerivationOutputsAndOptPaths outputsAndOptPaths(const Store & store) const;
|
|
|
|
|
2020-07-12 15:26:30 +00:00
|
|
|
static std::string_view nameFromPath(const StorePath & storePath);
|
Allow remote builds without sending the derivation closure
Previously, to build a derivation remotely, we had to copy the entire
closure of the .drv file to the remote machine, even though we only
need the top-level derivation. This is very wasteful: the closure can
contain thousands of store paths, and in some Hydra use cases, include
source paths that are very large (e.g. Git/Mercurial checkouts).
So now there is a new operation, StoreAPI::buildDerivation(), that
performs a build from an in-memory representation of a derivation
(BasicDerivation) rather than from a on-disk .drv file. The only files
that need to be in the Nix store are the sources of the derivation
(drv.inputSrcs), and the needed output paths of the dependencies (as
described by drv.inputDrvs). "nix-store --serve" exposes this
interface.
Note that this is a privileged operation, because you can construct a
derivation that builds any store path whatsoever. Fixing this will
require changing the hashing scheme (i.e., the output paths should be
computed from the other fields in BasicDerivation, allowing them to be
verified without access to other derivations). However, this would be
quite nice because it would allow .drv-free building (e.g. "nix-env
-i" wouldn't have to write any .drv files to disk).
Fixes #173.
2015-07-17 15:57:40 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct Derivation : BasicDerivation
|
|
|
|
{
|
|
|
|
DerivationInputs inputDrvs; /* inputs that are sub-derivations */
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
|
|
|
|
/* Print a derivation. */
|
2019-12-05 18:11:09 +00:00
|
|
|
std::string unparse(const Store & store, bool maskOutputs,
|
|
|
|
std::map<std::string, StringSet> * actualInputs = nullptr) const;
|
|
|
|
|
|
|
|
Derivation() { }
|
2003-07-20 19:29:38 +00:00
|
|
|
};
|
|
|
|
|
2003-07-15 16:28:54 +00:00
|
|
|
|
2016-02-04 13:48:42 +00:00
|
|
|
class Store;
|
2011-08-31 21:11:50 +00:00
|
|
|
|
2020-03-21 15:07:16 +00:00
|
|
|
enum RepairFlag : bool { NoRepair = false, Repair = true };
|
2011-08-31 21:11:50 +00:00
|
|
|
|
2005-01-19 14:36:00 +00:00
|
|
|
/* Write a derivation to the Nix store, and return its path. */
|
2020-08-23 15:00:25 +00:00
|
|
|
StorePath writeDerivation(Store & store,
|
2020-08-09 20:32:35 +00:00
|
|
|
const Derivation & drv, RepairFlag repair = NoRepair);
|
2003-07-10 18:48:11 +00:00
|
|
|
|
2014-04-08 17:24:29 +00:00
|
|
|
/* Read a derivation from a file. */
|
2020-08-01 19:38:35 +00:00
|
|
|
Derivation parseDerivation(const Store & store, std::string && s, std::string_view name);
|
2003-07-16 11:05:59 +00:00
|
|
|
|
2019-12-05 18:11:09 +00:00
|
|
|
// FIXME: remove
|
2005-01-19 14:36:00 +00:00
|
|
|
bool isDerivation(const string & fileName);
|
|
|
|
|
2020-09-04 15:15:51 +00:00
|
|
|
/* Calculate the name that will be used for the store path for this
|
|
|
|
output.
|
|
|
|
|
|
|
|
This is usually <drv-name>-<output-name>, but is just <drv-name> when
|
|
|
|
the output name is "out". */
|
2020-08-07 19:09:26 +00:00
|
|
|
std::string outputPathName(std::string_view drvName, std::string_view outputName);
|
|
|
|
|
2020-06-21 16:43:17 +00:00
|
|
|
// known CA drv's output hashes, current just for fixed-output derivations
|
|
|
|
// whose output hashes are always known since they are fixed up-front.
|
|
|
|
typedef std::map<std::string, Hash> CaOutputHashes;
|
|
|
|
|
2020-03-19 04:37:57 +00:00
|
|
|
typedef std::variant<
|
|
|
|
Hash, // regular DRV normalized hash
|
2020-06-21 16:43:17 +00:00
|
|
|
CaOutputHashes
|
2020-03-19 04:37:57 +00:00
|
|
|
> DrvHashModulo;
|
|
|
|
|
|
|
|
/* Returns hashes with the details of fixed-output subderivations
|
|
|
|
expunged.
|
|
|
|
|
|
|
|
A fixed-output derivation is a derivation whose outputs have a
|
|
|
|
specified content hash and hash algorithm. (Currently they must have
|
|
|
|
exactly one output (`out'), which is specified using the `outputHash'
|
|
|
|
and `outputHashAlgo' attributes, but the algorithm doesn't assume
|
2020-03-20 03:37:52 +00:00
|
|
|
this.) We don't want changes to such derivations to propagate upwards
|
2020-03-19 04:37:57 +00:00
|
|
|
through the dependency graph, changing output paths everywhere.
|
|
|
|
|
|
|
|
For instance, if we change the url in a call to the `fetchurl'
|
2020-03-20 03:37:52 +00:00
|
|
|
function, we do not want to rebuild everything depending on it---after
|
|
|
|
all, (the hash of) the file being downloaded is unchanged. So the
|
|
|
|
*output paths* should not change. On the other hand, the *derivation
|
|
|
|
paths* should change to reflect the new dependency graph.
|
2020-03-19 04:37:57 +00:00
|
|
|
|
2020-03-20 03:38:51 +00:00
|
|
|
For fixed-output derivations, this returns a map from the name of
|
|
|
|
each output to its hash, unique up to the output's contents.
|
2020-03-19 04:37:57 +00:00
|
|
|
|
|
|
|
For regular derivations, it returns a single hash of the derivation
|
|
|
|
ATerm, after subderivations have been likewise expunged from that
|
|
|
|
derivation.
|
|
|
|
*/
|
|
|
|
DrvHashModulo hashDerivationModulo(Store & store, const Derivation & drv, bool maskOutputs);
|
2011-07-20 18:10:47 +00:00
|
|
|
|
|
|
|
/* Memoisation of hashDerivationModulo(). */
|
2020-03-19 04:37:57 +00:00
|
|
|
typedef std::map<StorePath, DrvHashModulo> DrvHashes;
|
2011-07-20 18:10:47 +00:00
|
|
|
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
extern DrvHashes drvHashes; // FIXME: global, not thread-safe
|
2011-07-20 18:10:47 +00:00
|
|
|
|
2012-11-26 16:15:09 +00:00
|
|
|
bool wantOutput(const string & output, const std::set<string> & wanted);
|
2012-11-26 14:39:10 +00:00
|
|
|
|
Allow remote builds without sending the derivation closure
Previously, to build a derivation remotely, we had to copy the entire
closure of the .drv file to the remote machine, even though we only
need the top-level derivation. This is very wasteful: the closure can
contain thousands of store paths, and in some Hydra use cases, include
source paths that are very large (e.g. Git/Mercurial checkouts).
So now there is a new operation, StoreAPI::buildDerivation(), that
performs a build from an in-memory representation of a derivation
(BasicDerivation) rather than from a on-disk .drv file. The only files
that need to be in the Nix store are the sources of the derivation
(drv.inputSrcs), and the needed output paths of the dependencies (as
described by drv.inputDrvs). "nix-store --serve" exposes this
interface.
Note that this is a privileged operation, because you can construct a
derivation that builds any store path whatsoever. Fixing this will
require changing the hashing scheme (i.e., the output paths should be
computed from the other fields in BasicDerivation, allowing them to be
verified without access to other derivations). However, this would be
quite nice because it would allow .drv-free building (e.g. "nix-env
-i" wouldn't have to write any .drv files to disk).
Fixes #173.
2015-07-17 15:57:40 +00:00
|
|
|
struct Source;
|
|
|
|
struct Sink;
|
|
|
|
|
2020-07-12 15:02:36 +00:00
|
|
|
Source & readDerivation(Source & in, const Store & store, BasicDerivation & drv, std::string_view name);
|
2019-12-05 18:11:09 +00:00
|
|
|
void writeDerivation(Sink & out, const Store & store, const BasicDerivation & drv);
|
2012-11-26 14:39:10 +00:00
|
|
|
|
2020-09-04 15:15:51 +00:00
|
|
|
/* This creates an opaque and almost certainly unique string
|
|
|
|
deterministically from the output name.
|
|
|
|
|
|
|
|
It is used as a placeholder to allow derivations to refer to their
|
|
|
|
own outputs without needing to use the hash of a derivation in
|
|
|
|
itself, making the hash near-impossible to calculate. */
|
2016-08-17 13:12:54 +00:00
|
|
|
std::string hashPlaceholder(const std::string & outputName);
|
|
|
|
|
2020-09-04 15:15:51 +00:00
|
|
|
/* This creates an opaque and almost certainly unique string
|
|
|
|
deterministically from a derivation path and output name.
|
|
|
|
|
|
|
|
It is used as a placeholder to allow derivations to refer to
|
|
|
|
content-addressed paths whose content --- and thus the path
|
|
|
|
themselves --- isn't yet known. This occurs when a derivation has a
|
|
|
|
dependency which is a CA derivation. */
|
2020-08-21 19:35:35 +00:00
|
|
|
std::string downstreamPlaceholder(const Store & store, const StorePath & drvPath, std::string_view outputName);
|
2020-08-07 19:09:26 +00:00
|
|
|
|
2006-09-04 21:06:23 +00:00
|
|
|
}
|