guile-user
[Top][All Lists]
Advanced

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

Re: [ANN] Guile Hall Release (v0.1.1)


From: Alex Sassmannshausen
Subject: Re: [ANN] Guile Hall Release (v0.1.1)
Date: Mon, 02 Jul 2018 11:39:21 +0200
User-agent: mu4e 1.0; emacs 26.1

Hi Amirouche,

Amirouche Boubekki writes:

> On 2018-07-01 14:07, Alex Sassmannshausen wrote:
>> Hello,
>>
>> It is with great trepidation and joy that I finally release Hall to the
>> world.
>>
>> You can get it with Guix after pulling the latest version with
>> $ guix package -i guile-hall
>>
>> Otherwise you can get the code from
>> https://gitlab.com/a-sassmannshausen/guile-hall/, and build (hopefully)
>> using the traditional
>
> This is nicely put. I will try to use to port the work I've done in chez
> and compare both approaches or maybe bundle guile-web with it.
>
> Do you recommend rebasing a project that has already autotools support
> to use hall?

It depends…

On the one hand, if:
- you are comfortable with autotools
- your project includes non-guile modules that need to be installed
- your project has a complicated project hierarchy

Then it might not be worth using Hall.  In the last case you might still
use Hall to generate Guix files, but to be honest, that doesn't gain you
much.

On the other hand, if:
- your autotools-fu is cargo-culty (like mine is)
- your project is Guile only
- you find the steps of maintaining the autotools infrastructure and
  rolling releases a pain

Then you might well benefit from switching to Hall.

It is definitely possible to use hand-written configure.ac files &
Makefile.am files with Hall: it simply does not touch those files.  On
the other hand, one of the nice things about Hall is that you can
regenerate a lot of the "infrastructure" files easily (autotools, basic
documentation, guix), and that feature obviously becomes more attractive
if you fully convert to the Hall way.

In any case, if you do want to give it a go, you probably want to use
$ hall init --convert [project-name] --author=$author

It will output the files to be generated, have a look whether that seems
sensible, then run with the --execute flag to create the files.

Then open the generated hall.scm file and try to map your project
folder-hierarchy to the files section.

Alternatively you could give
$ hall scan
a shot.  It will try to generate a new hall.scm file on the basis of
your project hierarchy — bit it may fail to do so.

You can then run with --execute if you actually want to update your
hall.scm file.

I would suggest, play around.  Though you'll probably find it way more
satisfying to use from the get go in a new project as you get the
expected user journey.

> Thanks for sharing!

My pleasure :)

Alex



reply via email to

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