guix-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 01/01: gnu: guile-hall: Update to 0.2.


From: Alex Sassmannshausen
Subject: Re: 01/01: gnu: guile-hall: Update to 0.2.
Date: Sat, 16 Feb 2019 14:11:00 +0100
User-agent: mu4e 1.0; emacs 26.1

Hello,

Ricardo Wurmus writes:

> Hi Alex,
>
>> You're right, this is incorrect.  One of the points of Hall is to
>> generate reproducible guix packages — but currently they default to
>> using (guix licenses) without prefix.  The generated recipe hence has no
>> prefix. I will fix this.
>
> Oh, I see.  I did not immediately realize that this was a generated
> recipe.
>
>> Again, this is the result of auto-generation: Hall generically wraps any
>> script files in the scripts directory of a project with all Guile
>> dependencies — rather than the developer having to manually specify
>> these things.
>
> I think this should rather be done by the guile-build-system.  We
> already do this in other build systems such as python-build-system.

That would be lovely as it reduces complexity of the code on the hall
side too :-)

I have to admit I'm somewhat worried about breaking Guix by adding code
to build systems.  I think the logic in hall to do this is fairly solid
— would it just be a matter of integrating this in the
guile-build-system?

I guess another issue is that hall genrates autotools compliant code for
now, which means that it uses gnu-build-system rather than
guile-build-system.

Maybe we'll either need to extend guile-build-system to handle autotools
logic or extend gnu-build-system to do guile wrapping (this feels wrong
though).

What do you think?

>> - hiding the complexity inside a build system for Guix, which carries
>>   out the steps currently added by Hall explicitly.
>
> This seems to be the best way forward.
>
>> I can also see that you have fixed my commit and tweaked it in several
>> ways — thank you for doing this.
>>
>> Are the steps you carried out "the recommended way" of doing things now?
>> If so then I can adapt hall to default to this workflow, so we can
>> encourage new contributors to do "the right thing".
>
> I had a few more changes that I intended to push but then stopped to
> write you.  In the case of guile-hall I think the wrapping could be
> greatly simplified, but that would not necessarily be possible in the
> generic case.  If we add this behaviour to the guile-build-system,
> however, Hall would not have to do any of this and the package
> definition could become simpler.

Agreed.

> I’m excited about Hall and would love to add support for it in Guile
> Studio (e.g. through a menu in the menu bar).

I was very excited to see that you went ahead and started the
"integrated Guile development environment" project with Guile Studio.  I
would love to have hall be part of that.

What is the best way to discuss taking this forward? Do you have an
issue tracker? Otherwise we could track it on the Hall tracker?

Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]