aboutsummaryrefslogtreecommitdiff
path: root/src/libstore/build.hh
AgeCommit message (Collapse)Author
2006-09-04* Use a proper namespace.Eelco Dolstra
* Optimise header file usage a bit. * Compile the parser as C++.
2006-03-06* `nix-env (-i|-u) --dry-run' now shows exactly which missing pathsEelco Dolstra
will be built or substituted.
2005-12-13* Change `referer' to `referrer' throughout. In particular, theEelco Dolstra
nix-store query options `--referer' and `--referer-closure' have been changed to `--referrer' and `--referrer-closure' (but the old ones are still accepted for compatibility).
2005-02-14* It is now possible to add store derivations or paths directly to aEelco Dolstra
user environment, e.g., $ nix-env -i /nix/store/z58v41v21xd3ywrqk1vmvdwlagjx7f10-aterm-2.3.1.drv or $ nix-env -i /nix/store/hsyj5pbn0d9iz7q0aj0fga7cpaadvp1l-aterm-2.3.1 This is useful because it allows Nix expressions to be bypassed entirely. For instance, if only a nix-pull manifest is provided, plus the top-level path of some component, it can be installed without having to supply the Nix expression (e.g., for obfuscation, or to be independent of Nix expression language changes or context dependencies).
2005-01-25* Maintain the references/referers relation also for derivations.Eelco Dolstra
This simplifies garbage collection and `nix-store --query --requisites' since we no longer need to treat derivations specially. * Better maintaining of the invariants, e.g., setReferences() can only be called on a valid/substitutable path.
2005-01-25* In nix-store: added query `--referers-closure' that returns theEelco Dolstra
closure of the referers relation rather than the references relation, i.e., the set of all paths that directly or indirectly refer to the given path. Note that contrary to the references closure this set is not fixed; it can change as paths are added to or removed from the store.
2005-01-20* Terminology fixes.Eelco Dolstra
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.