unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* On a Guile-based Build-Tool complimenting Guix
@ 2024-12-19 20:12 Divya Ranjan
  2024-12-19 21:08 ` Sergio Pastor Pérez
                   ` (4 more replies)
  0 siblings, 5 replies; 15+ messages in thread
From: Divya Ranjan @ 2024-12-19 20:12 UTC (permalink / raw)
  To: guix-devel; +Cc: pjotr.public12

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,
Philosophy, Mathematics, Libre Software.


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2024-12-28 17:51 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-19 20:12 On a Guile-based Build-Tool complimenting Guix Divya Ranjan
2024-12-19 21:08 ` Sergio Pastor Pérez
2024-12-28  1:55   ` Divya Ranjan
2024-12-19 21:17 ` Janneke Nieuwenhuizen
2024-12-20  0:06   ` indieterminacy
2024-12-28  1:53   ` Divya Ranjan
2024-12-19 21:33 ` Olivier Dion
2024-12-21  7:53   ` Pjotr Prins
2024-12-28  1:48     ` Divya Ranjan
2024-12-28  1:38   ` Divya Ranjan
2024-12-28 17:50   ` Ludovic Courtès
2024-12-20 17:31 ` Attila Lendvai
2024-12-28  1:43   ` Divya Ranjan
2024-12-27  0:41 ` Fi
2024-12-28  1:51   ` Divya Ranjan

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).