[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Prototype register-path

From: Ludovic Courtès
Subject: Re: [PATCH] Prototype register-path
Date: Mon, 19 Jun 2017 13:56:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)


Caleb Ristvedt <address@hidden> skribis:

> Well, I took a look at libstore/, and that is a lot of code. I
> hope I can get away with only reading as much as is necessary to clarify
> details. To that end, I'd like to make sure that my high-level
> understanding of the build process is accurate.
> - A derivation is a node in a (acyclic?) graph of "what depends on what" or,
>   alternately put, what is input to what.

Yes, a directed acyclic graph.

> - Derivations can depend on other derivations or plain files (can those files 
> be
>   directories?), where "plain files" cannot depend on anything else.

Right, “plain files” are referred to as “sources” in the code (e.g., the
‘sources’ field of <derivation>).  “Sources” are content-addressable
things added with ‘add-text-to-store’, ‘add-to-store’, and similar.

> - "Building" a derivation involves first ensuring that all of its inputs are
>   "built" (in the case of inputs that are derivations, this means ensuring its
>   output exists as a store item, and if not, producing it by this same
>   process. In the case of plain file inputs, this means just ensuring that 
> they
>   exist as a store item), and then preparing a build environment. The 
> "builder"
>   script is then executed in a chroot rooted under the build tree. After it 
> has
>   completed, the output (where is it put during the build process?) from
>   building the derivation is placed in the store (and registered).


> - "preparing a build environment" involves first creating a directory in which
>   the build will be run, then populating it with certain expected files and
>   directories (as detailed in 2.4.1 of the manual). Also, the store items
>   produced from building the inputs need to somehow be made available (is 
> there
>   a gnu/store/ under the build tree? I feel like I don't quite understand 
> where
>   everything goes in the build tree). Also, set any environment variables
>   associated with the derivation.

Yes.  In the build environment, there’s the subset of /gnu/store that is
explicitly declared as a dependency, directly or indirectly.  For
example, we can see it here:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(guix)
scheme@(guile-user)> ,enter-store-monad
store-monad@(guile-user) [1]> (gexp->derivation "contents"
                                                    (use-modules (ice-9 ftw))
                                                      (lambda (port)
                                                        (write (scandir 
"/gnu/store") port)))))
$2 = #<derivation /gnu/store/8r9l9n9vv8vsnjy1b7w15bp8liz9bcvh-contents.drv => 
/gnu/store/a1z90bzb7xl6glp033jkxjc1n3w0lw7w-contents 41847d0>
store-monad@(guile-user) [1]> (built-derivations (list $2))
$3 = #t
store-monad@(guile-user) [1]> ,q
scheme@(guile-user)> ,pp (call-with-input-file (derivation->output-path $2) 
$4 = ("."
--8<---------------cut here---------------end--------------->8---

What we see above is Guile and its dependencies, along with the output
and its build script.

> Assuming I've got the gist of it sort of right, that leaves one more question:
> how are hashes for the paths computed? It's not sha256 like the database 
> hashes,
> it seems to be 160 bits in size. How are all the inputs hashed together? Are 
> all
> the inputs put in one big directory and that is hashed in nar form, or what? 
> And
> what about store items that don't have any inputs (for example, something 
> placed
> in there with add-text-to-store)? I suppose in that case they are their own
> input, perhaps?

See (guix derivations) for how these hashes are computed, and also
‘store-path’, ‘output-path’, and ‘fixed-output-path’ in (guix store).
Normally you won’t have to reimplement any of these.

> Some of those answers might be in the manual, but I didn't manage to
> find them.

The manual doesn’t tell much about internal APIs.  :-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]