3 ms·

GNU Make's Guile integration is such a cool feature. The one hiccup with it is that isn't included in the default GNU Make package on any system I've ever used

GNU Make's Guile integration is such a cool feature. The one hiccup with it is that isn't included in the default GNU Make package on any system I've ever used (although it can be installed as make-guile in a few distros). I'm guessing it's because Guile is around the same installed size as Python, and it needs a lot of external dependencies - one of which (the garbage-collection library) is a little oddball. A tool as foundational as Make probably doesn't want to pull in a huge dependency tree if avoidable. If we want to see Guile support added to Make by default, we'll need to reduce or eliminate Guile's external dependencies and slim down the install.

LukeShu 7y ago
It's enabled in the `make` package on Arch Linux. My Guile is around 40MB; my Python is around 80MB--both gargantuan compared to the 1.5MB Make.
aijony 7y ago
Is it cheating if we count GNU Guix?
dfox 7y ago
What exactly is "oddball" about BDW GC?
- antonvs 7y ago
  What isn't oddball about it? It's designed to work as a garbage-collected replacement for C's malloc. That alone is enough to establish its oddballness. Any large system that makes the mistake of using it soon discovers its limitations. Not that it's a bad system per se - it achieves its design goals, it's just that its design goals are, to put it mildly, oddball. Basically, it's designed to allow systems that really should be written in a garbage-collected language, to kinda-sorta get away without that - up to a point.
  - dfox 7y ago
    You should not think of it as malloc replacement but as an GC that can work with native code that does not use fixed stack and register layout. That you can use such a thing for code generated by C compiler is side effect of that. In fact, there are various garbage collected runtimes with bespoke GC's that use similar implementation strategies. Edit: and one notable thing on BDW GC is its non-oddballness when it comes to building and/or packaging it. Also it is almost completely written in portable-ish C (it expects sane memory layout and relies on bunch of technically unspecified, but expected behaviors).
    - antonvs 7y ago
      The point is that it's designed to work with native code in a language that wasn't designed to use garbage collection. That's going to result in a semantic gap no matter what, and it invariably does. Every system I've ever seen using Boehm GC has issues as a result, except in certain special circumstances where the limitations are mitigated by the nature of the system. That's not an indictment of the GC itself, it's simply a consequence of trying to shoehorn automatic GC into a language that doesn't support it.
  - int_19h 7y ago
    It also allows language implementations to get a GC that, while not perfect, is "good enough" in many cases - and can get them through the early growth period. The library has APIs to manually manage roots etc for this purpose. I remember that Mono used it early on. Not really surprising that Guile does, as well. Nor is it surprising that they haven't switched to a better hand-rolled GC - given the relative obscurity of Guile, I would imagine that its maintainers have more important things to work on.
- nrclark 7y ago
  The license is a little weird, for one. It's also strange because I think it's the only non-GNU dependency in the whole chain. I guess I'd also have expected a GC scheme to be baked into the core Guile source-code instead of relying on an external GC library. It's also not fully portable C code. I'm sure the library works great - it has a long history, and I'm definitely not knocking it. But it's a little bit of an unexpected dependency for sure.
ratboy666 7y ago
: fred@tara ~ $; cat /etc/fedora-release Fedora release 31 (Thirty One) : fred@tara ~ $; make -p | grep FEAT make: *** No targets specified and no makefile found. Stop. .FEATURES := target-specific order-only second-expansion else-if shortest-stem undefine oneshell archives jobserver output-sync check-symlink guile load : fred@tara ~ $; guile available -- so, its enabled in Fedora. : fred@tara ~ $; ls -l `which make` -rwxr-xr-x. 1 root root 248624 Dec 10 17:34 /usr/bin/make : fred@tara ~ $; and, just to validate guile availability: : fred@tara ~ $; ldd `which make` linux-vdso.so.1 (0x00007ffce61cb000) libguile-2.2.so.1 => /lib64/libguile-2.2.so.1 (0x00007fc423432000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fc42342b000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc423409000) libc.so.6 => /lib64/libc.so.6 (0x00007fc423240000) libgc.so.1 => /lib64/libgc.so.1 (0x00007fc4230e1000) libffi.so.6 => /lib64/libffi.so.6 (0x00007fc4230d6000) libunistring.so.2 => /lib64/libunistring.so.2 (0x00007fc422f50000) libgmp.so.10 => /lib64/libgmp.so.10 (0x00007fc422ed3000) libltdl.so.7 => /lib64/libltdl.so.7 (0x00007fc422ec7000) libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007fc422e8c000) libm.so.6 => /lib64/libm.so.6 (0x00007fc422d46000) /lib64/ld-linux-x86-64.so.2 (0x00007fc4235ed000) libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 (0x00007fc422d41000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc422d25000) : fred@tara ~ $; Yes, libgc and libgmp are needed (182k for libgc, 1.3mb for libgmp, 1.3mb for libguile itself) as opposed to 3.3m for python3. Seems comparable, including dependencies.
- nrclark 7y ago
  Awesome, I didn't know it had landed in F31. Thanks for the comment. Re: size, I'm surprised by the library size. Is it possible that the library needs more files than just the .so? The guile-2.2-libs package is around 40-43 MB on the current Ubuntu LTS, plus a few more MB for supporting Guile packages. (source: https://packages.ubuntu.com/bionic/guile-2.2-libs https://packages.ubuntu.com/bionic/guile-2.2-libs)
- kristianp 7y ago
  ubuntu LTS's make is a lot leaner: $ ldd `which make` linux-vdso.so.1 (0x00007ffff9e87000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f27cd690000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f27cd290000) /lib64/ld-linux-x86-64.so.2 (0x00007f27cdc00000) $ ls -l `which make` -rwxr-xr-x 1 root root 222792 Apr 17 2018 /usr/bin/make $ make -p |grep FEAT make: *** No targets specified and no makefile found. Stop. .FEATURES := target-specific order-only second-expansion else-if shortest-stem undefine oneshell archives jobserver output-sync check-symlink load

LukeShu 7y ago

It's enabled in the `make` package on Arch Linux. My Guile is around 40MB; my Python is around 80MB--both gargantuan compared to the 1.5MB Make.

aijony 7y ago

Is it cheating if we count GNU Guix?

dfox 7y ago

What exactly is "oddball" about BDW GC?

antonvs 7y ago
What isn't oddball about it? It's designed to work as a garbage-collected replacement for C's malloc. That alone is enough to establish its oddballness. Any large system that makes the mistake of using it soon discovers its limitations. Not that it's a bad system per se - it achieves its design goals, it's just that its design goals are, to put it mildly, oddball. Basically, it's designed to allow systems that really should be written in a garbage-collected language, to kinda-sorta get away without that - up to a point.
- dfox 7y ago
  You should not think of it as malloc replacement but as an GC that can work with native code that does not use fixed stack and register layout. That you can use such a thing for code generated by C compiler is side effect of that. In fact, there are various garbage collected runtimes with bespoke GC's that use similar implementation strategies. Edit: and one notable thing on BDW GC is its non-oddballness when it comes to building and/or packaging it. Also it is almost completely written in portable-ish C (it expects sane memory layout and relies on bunch of technically unspecified, but expected behaviors).
  - antonvs 7y ago
    The point is that it's designed to work with native code in a language that wasn't designed to use garbage collection. That's going to result in a semantic gap no matter what, and it invariably does. Every system I've ever seen using Boehm GC has issues as a result, except in certain special circumstances where the limitations are mitigated by the nature of the system. That's not an indictment of the GC itself, it's simply a consequence of trying to shoehorn automatic GC into a language that doesn't support it.
- int_19h 7y ago
  It also allows language implementations to get a GC that, while not perfect, is "good enough" in many cases - and can get them through the early growth period. The library has APIs to manually manage roots etc for this purpose. I remember that Mono used it early on. Not really surprising that Guile does, as well. Nor is it surprising that they haven't switched to a better hand-rolled GC - given the relative obscurity of Guile, I would imagine that its maintainers have more important things to work on.
nrclark 7y ago
The license is a little weird, for one. It's also strange because I think it's the only non-GNU dependency in the whole chain. I guess I'd also have expected a GC scheme to be baked into the core Guile source-code instead of relying on an external GC library. It's also not fully portable C code. I'm sure the library works great - it has a long history, and I'm definitely not knocking it. But it's a little bit of an unexpected dependency for sure.

ratboy666 7y ago

: fred@tara ~ $; cat /etc/fedora-release Fedora release 31 (Thirty One) : fred@tara ~ $; make -p | grep FEAT make: *** No targets specified and no makefile found. Stop. .FEATURES := target-specific order-only second-expansion else-if shortest-stem undefine oneshell archives jobserver output-sync check-symlink guile load : fred@tara ~ $; guile available -- so, its enabled in Fedora. : fred@tara ~ $; ls -l `which make` -rwxr-xr-x. 1 root root 248624 Dec 10 17:34 /usr/bin/make : fred@tara ~ $; and, just to validate guile availability: : fred@tara ~ $; ldd `which make` linux-vdso.so.1 (0x00007ffce61cb000) libguile-2.2.so.1 => /lib64/libguile-2.2.so.1 (0x00007fc423432000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fc42342b000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc423409000) libc.so.6 => /lib64/libc.so.6 (0x00007fc423240000) libgc.so.1 => /lib64/libgc.so.1 (0x00007fc4230e1000) libffi.so.6 => /lib64/libffi.so.6 (0x00007fc4230d6000) libunistring.so.2 => /lib64/libunistring.so.2 (0x00007fc422f50000) libgmp.so.10 => /lib64/libgmp.so.10 (0x00007fc422ed3000) libltdl.so.7 => /lib64/libltdl.so.7 (0x00007fc422ec7000) libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007fc422e8c000) libm.so.6 => /lib64/libm.so.6 (0x00007fc422d46000) /lib64/ld-linux-x86-64.so.2 (0x00007fc4235ed000) libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 (0x00007fc422d41000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc422d25000) : fred@tara ~ $; Yes, libgc and libgmp are needed (182k for libgc, 1.3mb for libgmp, 1.3mb for libguile itself) as opposed to 3.3m for python3. Seems comparable, including dependencies.

nrclark 7y ago
Awesome, I didn't know it had landed in F31. Thanks for the comment. Re: size, I'm surprised by the library size. Is it possible that the library needs more files than just the .so? The guile-2.2-libs package is around 40-43 MB on the current Ubuntu LTS, plus a few more MB for supporting Guile packages. (source: https://packages.ubuntu.com/bionic/guile-2.2-libs https://packages.ubuntu.com/bionic/guile-2.2-libs)
kristianp 7y ago
ubuntu LTS's make is a lot leaner: $ ldd `which make` linux-vdso.so.1 (0x00007ffff9e87000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f27cd690000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f27cd290000) /lib64/ld-linux-x86-64.so.2 (0x00007f27cdc00000) $ ls -l `which make` -rwxr-xr-x 1 root root 222792 Apr 17 2018 /usr/bin/make $ make -p |grep FEAT make: *** No targets specified and no makefile found. Stop. .FEATURES := target-specific order-only second-expansion else-if shortest-stem undefine oneshell archives jobserver output-sync check-symlink load