#:modules and #:imported-modules, and more

[Tomas Volf]

Hello Guix.


Table of Contents
_________________

1. My understanding
2. #:extra-modules, #:extra-imported-modules
3. %...-build-system-modules
4. %default-modules
5. Other comments
.. 1. What are the reasons for the naming scheme of build systems?
6. Conclusion


1 My understanding
==================

  In the process of fixing crashes of libreoffice and netsurf (patches
  coming soon), I was trying to understand the difference between
  #:modules and #:imported-modules.  My conclusion is that the former
  are modules that are (use-modules)-ed automatically, while the latter
  are modules that are made available and can be (use-modules)-ed if
  desired.

  If one wants to add some modules, the way it is done, for
  gnu-build-system, is like this:

  ,----
  | #:imported-modules `((some module)
  |                      ,@gnu-build-system-modules)
  `----

  Is that summary correct?

  Assuming it is, I would like to propose few changes.  I am willing to
  supply the implementation(s), but thought I should discuss it first in
  order not to waste time if it would be a no-go.  They would be done in
  roughly this order over multiple patch series to allow smooth
  transition.


2 #:extra-modules, #:extra-imported-modules
===========================================

  As seen in the example above, currently there is a need to manually
  merge the list of additional modules with the original one.  Failing
  to use the correct base can lead to issues (like crash in netsurf).

  I would like to propose adding two new fields into the build system,
  `#:extra-modules' and `#:extra-imported-modules'.  Those would be
  automatically appended to the `#:modules' and `#:imported-modules',
  removing the need to merge the lists in the package definition.
  Therefore the example above would turn into:

  ,----
  | #:extra-imported-modules '((some module))
  `----

  The original fields would still be available, so full control would be
  possible, if needed.

  There currently seems to be ~276 occurrences of
  `-build-system-modules' in the gnu/packages directory, and vast
  majority of them would be removed.


3 %...-build-system-modules
===========================

  This variable seems misnamed, since it should be used with
  `#:imported-modules', so once the above is done (and the usage of it
  drops down), I would like to rename it to
  `%...-build-system-imported-modules'.


4 %default-modules
==================

  Situation with `#:modules' is more interesting, since there is no
  common pattern.  Some build systems have `%default-modules'
  (non-exported), some just hard-code the list.  In the step above the
  binding was released, so I would like to unify the build systems by
  reusing as public `%...-build-system-modules', which would be used as
  default for `#:modules' in all build systems.

  These steps are somewhat independent, but at least this last one I
  would think would be useful.  Albeit without the previous ones
  different name would have to be used.


5 Other comments
================

5.1 What are the reasons for the naming scheme of build systems?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  It seems that all the build systems use a prefix-based naming scheme,
  so `gnu-build-system', `meson-build-system' and such.  I am curious
  what is the reason for that?  Since Guile modules support `#:prefix',
  would it not be a cleaner choice?

  So I could have something like:

  ,----
  | (define-module (gnu packages foo)
  |   #:use-module ((guix build-system gnu)    #:prefix gnu)
  |   #:use-module ((guix build-system python) #:prefix python))
  |   ...)
  |
  | (define-public bar
  |   (package
  |     ...
  |     (build-system gnu:build-system)))
  |
  | (define-public baz
  |   (package
  |     ...
  |     (build-system python:build-system)))
  `----

  That, given there is a built-in support in the language, seems
  somewhat cleaner.  And could possibly make introspection easier
  (maybe?).  Could someone enlighten me regarding the reasons for the
  current implementation?


6 Conclusion
============

  Thank you for considering this proposal, and thank you in advance for
  any helpful insight you are willing to provide.



Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

signature.asc
Description: PGP signature