doc: Expound on the build-side versus host-side modules topic.
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: I06975fb24f0d67c833884313a727dc550f61d8a0master
parent
e4443561d2
commit
7d3f2b99ff
|
@ -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{})}.
|
||||
|
|
Reference in New Issue