aboutsummaryrefslogtreecommitdiff
path: root/src/libstore/derivations.hh
AgeCommit message (Collapse)Author
2017-07-03Replace a few bool flags with enumsEelco Dolstra
Functions like copyClosure() had 3 bool arguments, which creates a severe risk of mixing up arguments. Also, implement copyClosure() using copyPaths().
2016-08-17Add a mechanism for derivation attributes to reference the derivation's outputsEelco Dolstra
For example, you can now say: configureFlags = "--prefix=${placeholder "out"} --includedir=${placeholder "dev"}"; The strings returned by the ‘placeholder’ builtin are replaced at build time by the actual store paths corresponding to the specified outputs. Previously, you had to work around the inability to self-reference by doing stuff like: preConfigure = '' configureFlags+=" --prefix $out --includedir=$dev" ''; or rely on ad-hoc variable interpolation semantics in Autoconf or Make (e.g. --prefix=\$(out)), which doesn't always work.
2016-07-26makeFixedOutputPath(): Drop superfluous HashType argumentEelco Dolstra
2016-06-01Make the store directory a member variable of StoreEelco Dolstra
2016-02-04StoreAPI -> StoreEelco Dolstra
Calling a class an API is a bit redundant...
2016-02-04Eliminate the "store" global variableEelco Dolstra
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.)
2015-07-17Allow remote builds without sending the derivation closureEelco Dolstra
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-06-10Export outputPaths functionEelco Dolstra
This is useful for the new hydra-queue-runner.
2014-04-08If a .drv cannot be parsed, show its pathEelco Dolstra
Otherwise you just get ‘expected string `Derive(['’ which isn't very helpful.
2012-11-26Only substitute wanted outputs of a derivationEelco Dolstra
If a derivation has multiple outputs, then we only want to download those outputs that are actuallty needed. So if we do "nix-build -A openssl.man", then only the "man" output should be downloaded. Likewise if another package depends on ${openssl.man}. The tricky part is that different derivations can depend on different outputs of a given derivation, so we may need to restart the corresponding derivation goal if that happens.
2012-11-26Make "nix-build -A <derivation>.<output>" do the right thingEelco Dolstra
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.
2012-10-03Add a ‘--repair’ flag to nix-instantiateEelco Dolstra
This allows repairing corrupted derivations and other source files.
2012-09-11Include config.h before any other headerEelco Dolstra
"config.h" must be included first, because otherwise the compiler might not see the right value of _FILE_OFFSET_BITS. We've had this before; see 705868a8a96a10f70e629433cfffc2d5cd2703eb. In this case, GCC would compute a different address for ‘settings.useSubstitutes’ in misc.cc because of the off_t in ‘settings’. Reverts 3854fc9b42d16b810f62b64194b699033b03aaf1. http://hydra.nixos.org/build/3016700
2012-07-18Use "#pragma once" to prevent repeated header file inclusionEelco Dolstra
2011-08-31* Eliminate all uses of the global variable ‘store’ from libstore.Eelco Dolstra
This should also fix: nix-instantiate: ./../boost/shared_ptr.hpp:254: T* boost::shared_ptr<T>::operator->() const [with T = nix::StoreAPI]: Assertion `px != 0' failed. which was caused by hashDerivationModulo() calling the ‘store’ object (during store upgrades) before openStore() assigned it.
2011-07-20* Fix a huuuuge security hole in the Nix daemon. It didn't check thatEelco Dolstra
derivations added to the store by clients have "correct" output paths (meaning that the output paths are computed by hashing the derivation according to a certain algorithm). This means that a malicious user could craft a special .drv file to build *any* desired path in the store with any desired contents (so long as the path doesn't already exist). Then the attacker just needs to wait for a victim to come along and install the compromised path. For instance, if Alice (the attacker) knows that the latest Firefox derivation in Nixpkgs produces the path /nix/store/1a5nyfd4ajxbyy97r1fslhgrv70gj8a7-firefox-5.0.1 then (provided this path doesn't already exist) she can craft a .drv file that creates that path (i.e., has it as one of its outputs), add it to the store using "nix-store --add", and build it with "nix-store -r". So the fake .drv could write a Trojan to the Firefox path. Then, if user Bob (the victim) comes along and does $ nix-env -i firefox $ firefox he executes the Trojan injected by Alice. The fix is to have the Nix daemon verify that derivation outputs are correct (in addValidPath()). This required some refactoring to move the hash computation code to libstore.
2010-05-12* Sync with the trunk.Eelco Dolstra
2010-04-19* Don't use the ATerm library for parsing/printing .drv files.Eelco Dolstra
2010-03-02* When using the included sqlite/aterm libraries, build withEelco Dolstra
--enable-shared. * In libutil/libstore/libexpr etc., link against sqlite and aterm. * Some more header file hygiene.
2009-12-16* Build correctly against newer ATerm releases. Fixes "error: 'union'Eelco Dolstra
tag used in naming 'struct _ATerm'".
2006-09-04* Remove unnecessary inclusions of aterm2.h.Eelco Dolstra
2006-09-04* Use a proper namespace.Eelco Dolstra
* Optimise header file usage a bit. * Compile the parser as C++.
2005-01-20* Another change to low-level derivations. The last one this year, IEelco Dolstra
promise :-) This allows derivations to specify on *what* output paths of input derivations they are dependent. This helps to prevent unnecessary downloads. For instance, a build might be dependent on the `devel' and `lib' outputs of some library component, but not the `docs' output.
2005-01-19* Renamed `normalise.cc' -> `build.cc', `storeexprs.cc' ->Eelco Dolstra
`derivations.cc', etc. * Store the SHA-256 content hash of store paths in the database after they have been built/added. This is so that we can check whether the store has been messed with (a la `rpm --verify'). * When registering path validity, verify that the closure property holds.