IRC channel logs
2024-04-06.log
back to list of logs
<janneke>any progress on a guile-based make replacement? <old>janneke: What do you mean? <civodul>janneke: i feel like over the last few days we grew a stronger motivation for that :-) <civodul>one way forward would be to have a Zuo port that works with Guile 2.0 through 3.0 and Mes <civodul>(or we could use Zuo as-is but it’s maybe ridiculous to throw a 3rd Scheme implementation in the mix) <janneke>old: i'm just having another fit of frustration/inspiration with build systems <janneke>there's potato-make and there was another recent effort that looked promising <old>I have a complete build system in Guile for more than a year now, not make base <old>I use it in my project that have a mix of guile and C code <old>no auto-nightmare or cmake backtrace <janneke>yeah, i was thinking of something like that, what's it called? <old>no name, it is embedded in my project for now. I'm trying to make it clean so that it can be reeused else where. I was aiming at "guile-project" <janneke>ah, hehe; then there's at least one other effort <old>So far, it supports configuration like autotool with auto-detection of toolchain, source directory, arch, etc. File system search for binaries, C header files, libraries, Guile module, Python3 module <old>Generation of .in template like automake <janneke>i seem to remember something called `trivial' or somesuch but cannot seem to find it <janneke>caching stuff on disc, breaking dependencies and then creating clever pseudo-targets, yuck! <old>and a rudimentary recursive dependencies builder <janneke>ah, 't was `bespoke', have you looked at that? <old>hmm no. never heard of that <old>Always used autotools <janneke>in a previous life, i (attempted to) build a generic make system in gnu make <janneke>iwbn to have a build in guile really taking off <old>anyway, will try to work on that soon and make it available/usable by others <rlb>...I noticed this a while back and thought it was interesting, but never got back to look closely: https://redo.readthedocs.io/en/latest/ Of course it's only (I think) addressing a bit of the broader autotools domain. <dsmith>Quite a few years ago, there was some talk of a make-alike in Guile. "cons" was the perfect name, but taken. "conjure" was the winning name. <dsmith>I think the project dissolved into the feature-creep shadow world of portability. Or something. <rlb>I've also imagined that something like python or guile or ... might be sufficient for many common cases, i.e. not part of a bootstrapping set, etc., and those tools already need to gather a lot of relevant info for the current platform when they build (i.e. endianness, type sizes, ...). But that's just been vague speculation :) <Arsen>there's great value in not having a programmable build system <Arsen>having a build system one can introspect without hitting the halting problem leads to great flexibility in interoperating with that build system <mwette>Is the original desire for bootstrapping? <rlb>My naive suspicion is that the pressures/complexities are going to eventually push turing completeness, and that without that assumption, you might end up with say something mirroring the yaml mess, but I may well be wrong. I also don't doubt that a fully declarative subset might be a good idea for (common) cases where it's sufficient -- but again, just speculating, and definitely not planning to pursue it anytime soon. <rlb>(And by yaml mess, in this, case, I specifically mean yaml itself, not the broader idea -- since my impression is that it's expanded to include all kinds of ad-hoc flexibility...) <Arsen>rlb: well, you can do it without painful to use procedural yaml ;P <rlb>Oh, sure, but doesn't meson bottom out in python itself? (I suppose I'd mostly just assumed...) <Arsen>it's just implemented in python.. or C, if you use muon <rlb>Ahh, ok. I've imagined I'd eventually look at it more closely, and again, I'm all in favor of what I think you're advocating, generally. <rlb>ACTION has been in part influenced by fights with POSIX make, but that's of course not remotely representative of what's *possible* :)