On Thu, Sep 11, 2025 at 8:55 PM Maxim Cournoyer <ma...@guixotic.coop> wrote: > Nikolaos Chatzikonstantinou <nchatz...@gmail.com> writes: > > I've compiled a list of Guile skeleton projects with Autotools > > (autoconf, automake) here: > > <https://codeberg.org/annoyingusername/guile-project-skeletons-autotools>. > > Hopefully this will be useful to others. I tried to cover all the > > cases that I could come up with. > > Are you aware of Hall [0]? It aims to automate the creation of an > Autotools-based > build system for Guile projects. > > I've used it too bootstrap the build system of this small piece of > software for example: https://gitlab.com/apteryks/x-resize > > [0] https://gitlab.com/a-sassmannshausen/guile-hall
Hall does not work with some of the cases that my examples deal with, namely Guile programs with C extensions or C programs with embedded Guile. Furthermore, Hall achieves the opposite of the intended effect, which was to make it easier for people to come into the language: the moment you stray away from the indicated path, you are forever lost. Ultimately, it is a bad idea to layer on top of Autotools because you're bound to reinvent its complexity. Generally, the build system aspect of Guile is somewhat ignored. See e.g. <https://lists.gnu.org/archive/html/guile-devel/2018-12/msg00002.html> from 2018 mentioned in Hall's source code <https://gitlab.com/a-sassmannshausen/guile-hall/-/blob/master/hall/workarounds.scm#L41-43>. There needs to be more work to fix Guile's documentation to ensure that others can find both the examples and the good practices (at least one set of advice that is functional) of using Guile. I do want to undertake it; I am hoping to at least grab the attention of people to discuss its aspects before I spend time on it. Regards, Nikolaos Chatzikonstantinou
