On Sun, Oct 5, 2025 at 7:38 PM Tomas Volf <[email protected]> wrote: > > Nikolaos Chatzikonstantinou <[email protected]> writes: > > > Hello list, > > > > 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. > > Looks interesting. I should probably find the time to publish my own > project blueprint repository. From my experience, the most annoying > part to get at least semi-right are dependency tracking and > documentation generation, so it would be nice if that was covered. > > I took a quick look at the repository and have few observations:
Hello, I looked at your observations. > - There is no way to specify warning and optimization levels for guild. Good point. I had to search a bit to find out what the right variable names would be, but I saw that guile itself uses $(GUILE_WARNINGS) $(GUILE_OPTIMIZATIONS) and I added those to the guild invocation. > - I never actually needed it, but cross compilation does not seem to be > supported. For good reason, I don't know how to cross compile. :) Some of these examples use C libraries too, so I would additionally need to cross compile those. People who care about cross compilations know how to add these details, so thankfully it shouldn't be too big of an issue. I could probably look at how Guile itself does it in its repository, but I don't want to bother with that right now. > - Tests are not compiled. At the time I thought that tests are run-once so I saw no reason to compile them. I figured that if the tests fail, the programmer will modify them (and/or the source itself) and re-check, so what is the point of compiling? On the other hand, I actually ran into a Guile bug (reported as bug#79479 in bug-guile) that *only* exhibits itself when the tests are uncompiled. Strange stuff. Other than that, do you have a good reason to suggest the compilation of the tests? > - I do not use GUILE_LDFLAGS at all, and the result still links and > works. So maybe it is not required? Not sure here. GUILE_LDFLAGS is used for the subprojects named "kiwi" and "lemon". Both of these use <libguile.h> and as such they require to link against -lguile-3.0. It will also include a -L in case it's installed in a path that the linker is not aware of. I use GUILE_CFLAGS that includes the corresponding -I for <libguile.h>, again for the same reasons as -L. I think such setups are very exotic, because a distro maintainer would have to install a pkg-config file that points to non-standard directories for guile, which is very weird. In that case, the loader will fail. One has to use GUILE_LIBS or GUILE_LTLIBS (in case of libtool) which additionally augments the search path. I did not use that, so I swapped GUILE_LDFLAGS for GUILE_LTLIBS to account for that strange setup (9e2bf52 in my repo). > Additionally, I would suggest to take look at bug 72130 and apply the > patches to the bundled test runner. (Bug link: <https://issues.guix.gnu.org/72130>.) I fixed the typo you mention so now my test-driver.scm ships as version 2025-10-13.01. The other issue about the summarized metadata being printed multiple times and being undefined behavior, I have not fixed yet. I have a poor grasp of what is going under the hood with all these tools (i.e. the perl script involved) I've tried reading the sections in the Automake manual but as usual it's all old cruft that nobody has bothered modernizing and I might lose my mind if I put too much effort into that. Another issue is that I'm using `config.texi.in` to provide the package version in the generated dcumentation where automake includes a feature that `version.texi` is supplemented by automake. I should replace it; but then `version.texi` is placed in the source directory ignoring the info-in-builddir option (which apparently is not recommended because only GNU make supports it?) On the other hand, config.texi.in should be useful because I can use it for the bug report address in configure.ac that version.texi does not provide. There's just too much madness involved with autotools. Regards, Nikolaos Chatzikonstantinou
