On 2025-04-15 19:01, Ludovic Courtès wrote:
> Hello,
>
> [email protected] writes:
>
>> Each build-system sets its own imported-modules and modules, but in the
>> case where we would want to generalize a function which takes a
>> build-system in its arguments, there doesn't seem to be a way to access
>> the imported-modules and modules from this build-system. (I have a
>> specific use-case in mind for extending/modifying arbitrary
>> build-systems, related to 68315).
>
> I’m not sure I understand how this information could be used, but…
I do use this functionality in a substitute-keywords-arguments context,
where we don't know the default (imported-)modules.
(substitute-keyword-arguments arguments
((#:imported-modules modules default-imported-modules)
`(,@more-modules ,@modules))
((#:modules modules default-modules)
`(,@more-modules ,@modules))
If you want that to be accessible for a generic build-system, IIUC you
need this information.
>> (set-procedure-properties!
>> gnu-build
>> `((imported-modules . ,%default-gnu-imported-modules)
>> (modules . ,%default-gnu-modules)))
>
> Instead of procedure properties (which are a hack, really), you could
> add one or two fields to <build-system> and be done with that.
That is true, although I was worried about breaking the API. I'll give
that a try, migrating my current approach for this one.
> Now, “imported modules” are information that is already part of the
> gexps.
> Why do we still have #:imported-modules, I wonder. :-)
I wonder now that I have a use-case if it would still work in the case
we remove the keyword. I'll see if that's still possible, if it is,
I'll do just that.
> [...]
> and it just works.
Yep! Part of 68315 was taking care of that ;)
--
Best regards,
Nicolas Graves
