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

[Ricardo Wurmus]

Hi Alex,

[-guix-commits, +guix-devel]

>>> 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?

Yes, it shouldn’t be difficult to add this to the guile-build-system as
a build phase.  You needn’t worry about breaking Guix.  Please send your
proposed patch to guix-patches and I’ll review it.

I thought that the wrapping logic looked a bit too complicated in
comparison with the wrapping phases that other build systems use.  Maybe
we can simplify this a little.

> 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.

What is “autotools compliant code”?  Does it generate configure.ac,
Makefile.am, and all that?  In that case the “guile-build-system” may
not be the best fit, because it is used for Guile packages that have no
proper 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).

Extending the guile-build-system would be simpler as it is based on the
gnu-build-system.  Currently, the guile-build-system deletes most build
phases and replaces the “build” phase with a custom phase that compiles
and installs the Guile modules.  We could make it a little smarter so
that it uses the gnu-build-system’s phases when autotools things are
detected.

Alternatively, we could ignore the autotools things that Hall generates
and consider those files to be needed only for platforms that don’t use
Guix.

>> 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?

Guile Studio has no home yet.  I think it’s fine to track progress on
integrating Hall in the Hall tracker.  A first step would be to think of
what parts of Hall should be exposed in an Emacs user interface and
how.  (Maybe this could be an independent minor mode that will be
installed and activated in Guile Studio by default?)

--
Ricardo