Re: Proposal: A new build-system API

[Mája Tomášek]

zimoun <zimon.toutoune@gmail.com> writes:

Hi,

Thanks for your reply, I appreciate you taking time to respond to my
silly message <3.

> Hi,
>
> Thanks for your comments.
>
> On lun., 26 sept. 2022 at 10:39, Mája Tomášek <maya.tomasek@disroot.org> 
> wrote:
>
>> (package
>>         ...
>>         (inputs list-of-inputs)
>>         (build-system some-build-system)
>>         (arguments (list-of-quoted #:key value))
>>         ...
>>         )
>
> [...]
>
>> (package
>>         ...
>>         (inputs list-of-inputs)
>>         (build-system
>>                 (some-build-system
>>                         (phases new-list-of-phases)
>>                         (strip-binaries? #f)))
>>         ...
>>         )
>
> Hum, from the surface, your proposal is to just move the arguments.
> Currently, ’arguments’ are related to ’build-system’ – therefore, I do
> not the difference between your proposal and the current situation.

The main point was to define a more ergonomic and sanitized way to
configure the build system. For example, there's currently no guarantee
that #:phases will contain list of functions and the error from that
will be cryptic. Contrast that with the service-configuration API. There
are field sanitizers that ensure that the configuration is propper and
easily one can introspect what the build system accepts and what are the
defaults.

>
> However, this…
>
>> (define-build-system some-build-system
>>                      (inherit gnu-build-system)
>>                      (name 'some)
>>                      (description "Some build system")
>>                      (phases %standard-phases)
>>                      (strip-binaries? #t)
>>                      ...
>>                      (builder (thunked)
>>                               (build-system->builder this-build-system))
>> )
>>
>> The build-system->builder method would generate the build, with
>> arguments properly adjusted, records translated into keyword arguments,
>> for a standard build system, the alternative,
>> would be to provide a (lambda (build-system)
>> some-code-that-returns-derivation).
>>
>> The current system is good, but when you need to write your own build
>> system, you needlessly need to write thins like ungexping arguments,
>> running gexp->derivation, which is really the system by which the guix
>> daemon operates, but which could really be abstracted away from the
>> build system developer. The code writing for a complete build system is 
>> repetetive
>> and complicated.
>
> …is something different.  Yeah, maybe some glue helpers could ease the
> creation of new build-system.  Nevertheless, please note that a
> build-system somehow needs some plumbing and I am not convinced that
> it would be doable to define a new build-system without diving in some
> G-exp here or there.
>
> I agree that the composition of existing bricks is not always
> straightforward and it could be improved, eventually. :-)

I understand that some gexps are nescessary, and I really do love gexps
:D. Yet my point was mostly on that as a build system developer, I need
to concern myself with store-monad and derivations, even though I am
more concerned with the package build steps.

Best regards,
Maya