Hello! Pjotr Prins <pjotr.publi...@thebird.nl> skribis:
> Indeed, I love working with Guix and developing with Guix. Guix takes > care of my deployment and configuration requirements. > > I have written some time in the past that with Guix you don't need > autotools. The main thing autotools solve is configuring the build for > an environment. At the same time, with Guix you get a predictable > environment, so a make file (or similar) suffices. It is what I do in > all my development projects - I don't use autotools to develop and > deploy them. It greatly simplifies my existence :). Indeed, I have > never liked autotools (essentially a nasty hack) and only used them > before Nix/Guix. So, my approach is the same as yours :) +1! If we could provide tooling with an abstraction level close to that of a makefile, that’d help a lot. Actually, just like we have ‘emacs-build-system’, we could very much add ‘guile-build-system’ for simple Guile packages that don’t need/use Autoconf & co. ‘guile-build-system’ would automatically run ‘guild compile’, ‘makeinfo’, etc. pretty much like we do here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n870 Once we have that, developers of Guile packages can simply drop a ‘.guix’ file in their project and use it with ‘guix environment’, ‘guix build’, and ‘guix package’. That’s coarser-grain than a makefile, of course, but would be a good first step to providing tooling for people working on Guile code. Any takers for ‘guile-build-system’? A next step could be to add a tool that understands a syntax like that of the guildhall, which gets us closer to the makefile/Makefile.am level of abstraction: https://github.com/ijp/guildhall/blob/master/docs/packaging.texi#L121 Ludo’.
