lix -

Age	Commit message (Collapse)	Author
2023-04-07	Finish converting existing comments for internal API docs (#8146)	John Ericson
	* Finish converting existing comments for internal API docs 99% of this was just reformatting existing comments. Only two exceptions: - Expanded upon `BuildResult::status` compat note - Split up file-level `symbol-table.hh` doc comments to get per-definition docs Also fixed a few whitespace goofs, turning leading tabs to spaces and removing trailing spaces. Picking up from #8133 * Fix two things from comments * Use triple-backtick not indent for `dumpPath` * Convert GNU-style `\`..'` quotes to markdown style in API docs This will render correctly.
2023-03-31	Ensure all headers have `#pragma once` and are in API docs	John Ericson
	`///@file` makes them show up in the internal API dos. A tiny few were missing `#pragma once`.
2023-01-11	Improve `OutputsSpec` slightly	John Ericson
	A few little changes preparing for the rest.
2023-01-10	Make clear that `StorePathWithOutputs` is a deprecated type	John Ericson
	- Add a comment - Put `OutputsSpec` in a different header (First part of #6815) - Make a few stray uses of it in new code use `DerivedPath` instead.
2022-05-03	nix profile: Support overriding outputs	Eelco Dolstra

2022-05-03	Allow selecting derivation outputs using 'installable!outputs'	Eelco Dolstra
	E.g. 'nixpkgs#glibc^dev,static' or 'nixpkgs#glibc^*'.
2021-04-05	buildable.{cc,hh} -> derived-path.{cc,hh}	John Ericson

2021-04-05	Rename Buildable	John Ericson

2021-04-05	Use `BuildableReq` for `buildPaths` and `ensurePath`	John Ericson
	This avoids an ambiguity where the `StorePathWithOutputs { drvPath, {} }` could mean "build `brvPath`" or "substitute `drvPath`" depending on context. It also brings the internals closer in line to the new CLI, by generalizing the `Buildable` type is used there and makes that distinction already. In doing so, relegate `StorePathWithOutputs` to being a type just for backwards compatibility (CLI and RPC).
2021-04-05	Move `StorePathWithOutput` utilities out of store class	John Ericson
	These are by no means part of the notion of a store, but rather are things that happen to use stores. (Or put another way, there's no way we'd make them virtual methods any time soon.) It's better to move them out of that too-big class then. Also, this helps us remove StorePathWithOutputs from the Store interface altogether next commit.
2021-04-05	Move `StorePathWithOutputs` into its own header/file	John Ericson
	In the following commits it will become less prevalent.