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
