4 ms·

Excited by the new release. I learned a little bit of Guile for scripting in Make, and I dig it. It's a little hard to include in my own designs though, as muc

Excited by the new release. I learned a little bit of Guile for scripting in Make, and I dig it. It's a little hard to include in my own designs though, as much as I'd like to do it. If I had a wish-list, it would be: - Make some of the dependencies (especially libgc) internal. - Reduce the installed size. - Consider adding a license exception that allows using Guile without inheriting GPLv3's Installation Instructions requirement, which prevents inclusion on a lot of commercial products (even as a standalone program for running scripts). The Guile team is doing great work, and I'll enjoy trying out 3.0 once it hits my distro packages. I just wish that it slotted better into more systems. There's some humor in the idea that Guile started out with the stated goal of being a Tcl killer. Years later, a Guile install is almost 8 times the size of a Tcl install and it introduces significant external dependencies. The licensing is also worse for inclusion in larger systems.

JNRowe 7y ago
> [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.
- nrclark 7y ago
  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.
  - JNRowe 7y ago
    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 https://mesonbuild.com
    - nrclark 7y ago
      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.

JNRowe 7y ago

> [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.

nrclark 7y ago
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.
- JNRowe 7y ago
  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 https://mesonbuild.com
  - nrclark 7y ago
    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.