This has reminded me of Make's built-in support for guile[1].
I've assumed that the fact that we don't use it means that it probably depends on an earlier guile, as many projects many that support "guile scripting" typically depend on ~v1.8; but that is just an assumption. Does anyone know what its status is? [1] https://www.gnu.org/software/make/manual/html_node/Guile-Integration.html Pjotr Prins <pjotr.publi...@thebird.nl> writes: > Hi jgart, > > zig as a build system is nice, but it is llvm bound and only targets > zig and C/C++. It does not handle packages, and that is a feature in > my book ;). Mind they are planning to go down the packaging route, > from what I can tell. > > There have been some older discussions about creating our own > replacement for autotools, cmake and others. I often fight these make > make systems - and meson and/or language specific build systems. It is > a time waster for programmers and none of these systems leverages the > power of Guix itself. I kinda settled for cmake because, even though > it is an effing dragon, at least I can make it work (pun intended). > > We need someone with deep experience in build systems to write a guile > replacement - generating ninja is one idea. That is my opinion :). I > would love a simple way to describe a project in guile. It should not > be too hard actually (famously that is how these projects start and > turn out to be a real time sink). Maybe someone wants to try with > guidance from us, or maybe we can do it when we get bored some day. > > Pj. > > On Fri, Jan 27, 2023 at 02:03:06AM +0000, jgart wrote: >> Can `zig-build-system` be an alternative to the `gnu-build-system`? >> >> https://ziglang.org/learn/why\_zig\_rust\_d\_cpp/#a-package-manager-and-build-system-for-existing-projects >> >> > Not only can you write Zig code instead of C or C++ code, but you >> can use Zig as a replacement for autotools, cmake, make, scons, >> ninja, etc. And on top of this, it (will) provide a package manager >> for native dependencies. This build system is intended to be >> appropriate even if the entirety of a project’s codebase is in C or >> C++. >> >> WDYT >>
