Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> [make guile extensions]

Just a note from someone who was bitten by GNU make and guile integration last year. Huge numbers of systems have old make versions with no support for guile extensions¹, and many systems that do have new enough releases require a separate package² to use it.

And yeah, I'd written all my fancy integrations before figuring out they'd be worthless :/ It did allow me to noodle over the build system for long enough to come with some real improvements though, so it wasn't all wasted.

1. Some presumably to stay on pre-GPL3 make

2. make-guile on Debian for example.



I had the same experience. I think the slow adoption of Make's Guile extension is precisely because of its larger dependency load. If Guile had the same set of dependencies as GNU Make, I bet we'd see more distros turn it on by default.


FWIW, I switched that same project to meson¹ about six months later with no pushback whatsoever. I expected there to be some, but it went through review with uniform agreement.

I'm not sure what that says. `apt install make-guile` vs `apt install meson` don't seem all that different, if it is just about dependencies. I think that means your point on licensing is probably the bigger issue, or that perhaps I just picked the wrong day to open a PR with a guile extension…

1. https://mesonbuild.com


My phrasing was a little ambiguous maybe. What I meant was that the regular `make` package from most distros isn't compiled with support for Guile. So _distros_ are the ones that aren't adopting it.

Make's Guile extensions will probably never see widespread use until distro packagers compile them in by default. And distro packagers don't necessarily want to do that, because it would mean a bunch of extra dependencies (including ~100MB of Guile) just to compile a core build-tool.

If `make-guile` remains an optional (and incompatible) package distinct from vanilla `make`, users like us won't be able to rely on its availability. Which means it won't see big adoption by users. And many distros aren't interested in increasing `make`'s dependency footprint to support a userbase that doesn't exist because of chicken-and-egg reasons.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: