On Fri, Sep 12, 2025 at 2:16 AM Maxim Cournoyer <[email protected]> wrote: > > Hi Nikolaos, > > Nikolaos Chatzikonstantinou <[email protected]> writes: > > > On Thu, Sep 11, 2025 at 8:55 PM Maxim Cournoyer <[email protected]> wrote: > >> Nikolaos Chatzikonstantinou <[email protected]> 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. > > It's true it won't work for every project (even the x-resize one above I > needed to add some fragment of autoconf in there manually I think), but > even for these more complex projects, it gives you a reasonable > Autoconf/Automake base to build on top, instead of having to come up > with everything from scratch. I think this is still valuable. > > > 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. > > More documentation would be useful, of course.
Sure, but do you have maintainer rights to Guile? I don't want to embark on this journey of improving Guile's documentation with regards to build systems if my patch is unwanted/gets ignored. In particular: 1) The issues with Guile and Autotools need to be outlined: a) Guile wants to install both source and compiled files b) Guile is second-class to Autotools (say, unlike C) and c) the mtime issue with the .scm.go rule that currently requires a "hack" to fix on Autotools. To be specific, I'm talking about Automake too when I mention Autotools. The examples in the manual only consider Autoconf. 2) More examples need to be included, both as snippets in the manual and full examples in the GNU Guile distribution. 3) The meta/guile.m4 file has issues that need fixing, for instance GUILE_SITE is a hardcoded path that disallows the use of --prefix. Regards, Nikolaos Chatzikonstantinou
