Hello! For what its worth, I mentioned it only in the capacity of the opportunity to share work with meson. So in answer, I meant a guile interface to meson, with the backend of meson remaining the same I develop a lot with the gnome ecosystem and the meson project makes accommodations for that although I am sure there are other nice options.
On 28. 12. 24 3:51, Divya Ranjan wrote: > Hello Fi, > > Would you prefer a guile interface to meson, or a meson replacement in Guile? > > Regards, > > > On 27 December 2024 00:41:33 GMT, Fi <lapearl...@disroot.org> wrote: > > I was thinking this the other day!, was wondering about how useful a > guile interface to meson would be. On 19. 12. 24 22:12, Divya Ranjan wrote: > > Hello Guix, The other day, after being frustrated of build systems > (auto-tools, meson, maven etc.), I wondered why doesn’t Guix which has such > powerful tools within it (`guix build`, `guix pack` etc.) also not have a > purely Guile-based build tool? After all, our goal is to make deployment, and > building both more declarative and away from the all-too-familiar “dependency > hell”. I am not exactly sure how I want to go with this, but I want to extend > (if needed) the capabilities of Guix, to allow the developer of a package to > use it also to build the package effectively replacing existing build tools. > Since we already have build-system, instead of executing make (or whatever > other tool) commands from it, we could modify it to itself have all those > things that a Makefile would have. The developer would use Guile to declare > their build config, I am again not sure what this might exactly look like, > but can’t we have it such that we provide the developer with some tools to > _declare_ a custom and package-specific build-system in Guile (just > like our familiar gnu-build-system), but this is purely in Guile and executes > whatever commands, path declarations and other interactions (such as calling > gcc) directly from Guile and not by just calling `make`. I haven’t thought > through this clearly, but even if this doesn’t work, the main idea I’d like > to propose is to fully replace existing build-tools by making a new Guile > build tool to work alongside Guix. Ideally, once the developer has a build > config ready, one can just wrap it up with a package definition in Guile, > just like the ones we create to package something upstream. This package > definition can then be used in `guix build -f package.scm` to result in a > fully transactional building process that focuses not on getting out of > dependency hell, but just declaring your config right. And all of this > without having to learn yet another build tool that might disappear, and of > course, without > leaving the comfortable world of Lisp (Scheme). I was indicated by > others that such an idea has previously been conceievd among Guix developers > themselves, namely as a GSoC proposal[0]. I couldn’t find if that has > progressed towards anything, nor could find anything in the mailing list. I > did see Pjotr volunteering to mentor for it, I’ve CC-ed them to see if > they’re still interested in such a project. Meanwhile, I’d like input from > other Guix core developers on what they think of this, and if they could > provide me with some leads on where to go with this. [0]: > https://libreplanet.org/wiki/Group:Guix/GSoC-2024 Regards, > > Divya Ranjan, Mathematics, Philosophy and Libre Software
