lix -

Age	Commit message (Collapse)	Author
2024-10-08	Fix gcc warning -Wmissing-field-initializers	Lulu
	The approach that was taken here was to add default values to the type definitions rather than specify them whenever they are missing. Now the only remaining warning is '-Wunused-parameter' which @jade said is usually counterproductive and that we can just disable it: https://git.lix.systems/lix-project/lix/issues/456#issuecomment-6617 So this change adds the flags '-Wall', '-Wextra' and '-Wno-unused-parameter', so that all warnings are enabled except for '-Wunused-parameter'. Change-Id: Ic223a964d67ab429e8da804c0721ba5e25d53012
2024-08-08	refactor: make HashType and Base enum classes for type safety	Jade Lovelace
	Change-Id: I9fbd55a9d50464a56fe11cb42a06a206914150d8
2023-08-25	Introduce `OutputName` and `OutputNameView` type aliases	John Ericson
	Hopefully they make the code easier to understand!
2023-07-20	Give `queryPartialDerivationOutputMap` an `evalStore` parameter	John Ericson
	This makes it more useful. In general, the derivation will be in one store, and the realisation info is in another. This also helps us avoid duplication. See how `resolveDerivedPath` is now simpler because it uses `queryPartialDerivationOutputMap`. In #8369 we get more flavors of derived path, and need more code to resolve them all, and this problem only gets worse. The fact that we need a new method to deal with the multiple dispatch is unfortunate, but this generally relates to the fact that `Store` is a sub-par interface, too bulky/unwieldy and conflating separate concerns. Solving that is out of scope of this PR. This is part of the RFC 92 work. See tracking issue #6316
2023-05-08	libstore: also pass unwanted outputs to the post-build-hook	Yorick van Pelt

2023-04-15	Introduce `SingleDrvOutputs`	John Ericson
	In many cases we are dealing with a collection of realisations, they are all outputs of the same derivation. In that case, we don't need "derivation hashes modulos" to be part of our map key, because the output names alone will be unique. Those hashes are still part of the realisation proper, so we aren't loosing any information, we're just "normalizing our schema" by narrowing the "primary key". Besides making our data model a bit "tighter" this allows us to avoid a double `for` loop in `DerivationGoal::waiteeDone`. The inner `for` loop was previously just to select the output we cared about without knowing its hash. Now we can just select the output by name directly. Note that neither protocol is changed as part of this: we are still transferring `DrvOutputs` over the wire for `BuildResult`s. I would only consider revising this once #6223 is merged, and we can mention protocol versions inside factored-out serialization logic. Until then it is better not change anything because it would come a the cost of code reuse.
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-30	Separate `path.hh` from `content-address.hh`	John Ericson
	It is good to separate concerns; `StorePath` (in general) has nothing to do with `ContentAddress` anyways. This reduces the diff from #3746.
2023-01-23	Better-scope `Store` forward declarations	John Ericson

2023-01-02	Fix why-depends for CA derivations (again)	Théophane Hufschmitt
	This has the same goal as b13fd4c58e81b2b2b0d72caa5ce80de861622610,but achieves it in a different way in order to not break `nix why-depends --derivation`.
2021-07-22	buildPaths(): Add an evalStore argument	Eelco Dolstra
	With this, we don't have to copy the entire .drv closure to the destination store ahead of time (or at all). Instead, buildPaths() reads .drv files from the eval store and copies inputSrcs to the destination store if it needs to build a derivation. Issue #5025.
2021-06-23	Properly fail when trying to register an incoherent realisation	regnat

2021-06-23	Pass more values by reference	Théophane Hufschmitt
	Rather than copying them around everywhere Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
2021-05-26	Aso track the output path of the realisation dependencies	regnat

2021-05-26	Add a method to compute the closure of a realisation	regnat
	Only considers the closure in term of `Realisation`, ignores all the opaque inputs. Dunno whether that’s the nicest solution, need to think it through a bit
2021-05-26	Add a dependencies field to DrvOutputInfo	regnat
	Currently never used, nor set but will be useful shortly
2021-03-15	Add some logic for signing realisations	regnat
	Not exposed anywhere, but built realisations are now signed (and this should be forwarded when copy-ing them around)
2021-02-23	Make the build-hook work with ca derivations	regnat
	- Pass it the name of the outputs rather than their output paths (as these don't exist for ca derivations) - Get the built output paths from the remote builder - Register the new received realisations
2021-02-05	Remove the `visit` machinery in `RealisedPath`	regnat
	In addition to being some ugly template trickery, it was also totally useless as it was used in only one place where I could replace it by just a few extra characters
2021-02-05	Move the GENERATE_CMP macro to its own file	regnat
	Despite being an ugly hack, it can probably be useful in a couple extra places
2021-01-28	Add a new Cmd type working on RealisedPaths	regnat
	Where a `RealisedPath` is a store path with its history, meaning either an opaque path for stuff that has been directly added to the store, or a `Realisation` for stuff that has been built by a derivation This is a low-level refactoring that doesn't bring anything by itself (except a few dozen extra lines of code :/ ), but raising the abstraction level a bit is important on a number of levels: - Commands like `nix build` have to query for the realisations after the build is finished which is fragile (see 27905f12e4a7207450abe37c9ed78e31603b67e1 for example). Having them oprate directly at the realisation level would avoid that - Others like `nix copy` currently operate directly on (built) store paths, but need a bit more information as they will need to register the realisations on the remote side
2020-12-11	Use the hash modulo in the derivation outputs	regnat
	Rather than storing the derivation outputs as `drvPath!outputName` internally, store them as `drvHashModulo!outputName` (or `outputHash!outputName` for fixed-output derivations). This makes the storage slightly more opaque, but enables an earlier cutoff in cases where a fixed-output dependency changes (but keeps the same output hash) − same as what we already do for input-addressed derivations.
2020-12-11	Store the realisations as JSON in the binary cache	regnat
	Fix #4332
2020-12-11	Store metadata about drv outputs realisations	regnat
	For each known realisation, store: - its output - its output path This comes with a set of needed changes: - New `realisations` module declaring the types needed for describing these mappings - New `Store::registerDrvOutput` method registering all the needed informations about a derivation output (also replaces `LocalStore::linkDeriverToPath`) - new `Store::queryRealisation` method to retrieve the informations for a derivations This introcudes some redundancy on the remote-store side between `wopQueryDerivationOutputMap` and `wopQueryRealisation`. However we might need to keep both (regardless of backwards compat) because we sometimes need to get some infos for all the outputs of a derivation (where `wopQueryDerivationOutputMap` is handy), but all the stores can't implement it − because listing all the outputs of a derivation isn't really possible for binary caches where the server doesn't allow to list a directory.