ryan77627/guix
1
0
Fork 0
mirror of https://git.in.rschanz.org/ryan77627/guix.git synced 2024-11-07 07:26:13 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

doc: Expound on the build-side versus host-side modules topic.

Browse source 
Discussed in <https://issues.guix.gnu.org/65924#98-lineno27>.

* doc/contributing.texi (Modules): Add new context indices, and provide a
real-life counter-example, and its ramifications.

Reported-by: Ludovic Courtès <ludo@gnu.org>
Change-Id: I06975fb24f0d67c833884313a727dc550f61d8a0
This commit is contained in:
Maxim Cournoyer 2023-10-17 03:13:52 -04:00
parent e4443561d2
commit 7d3f2b99ff
No known key found for this signature in database
GPG key ID: 1260E46482E63562
1 changed files with 7 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
doc/contributing.texi
View file

@ -1280,11 +1280,16 @@ implement low-level concepts, such as the @code{memoize} procedure.
@node Modules
@subsection Modules
@cindex build-side modules
@cindex host-side modules
Guile modules that are meant to be used on the builder side must live in
the @code{(guix build @dots{})} name space. They must not refer to
other Guix or GNU modules. However, it is OK for a ``host-side'' module
to use a build-side module.
to use a build-side module. As an example, the @code{(guix
search-paths)} module should not be imported and used by a package since
it isn't meant to be used as a ``build-side'' module. It would also
couple the module with the package's dependency graph, which is
undesirable.
Modules that deal with the broader GNU system should be in the
@code{(gnu @dots{})} name space rather than @code{(guix @dots{})}.