Skip to content(if available)orjump to list(if available)

GNU Make Standard Library

GNU Make Standard Library

80 comments

·February 5, 2025

t43562

GNU make now has a load directive which lets you load up functions written in C

    -load my_module.o
Your makefile can contain instructions to build my_module.o and they will be automatically triggered.

For example you can create an equality test that works in an expression (ifeq can't be used as part of an expression obviously). For example

  FILENAME=file.$(if $(equals $(compression_level),0),tar,.tar.bz3)
The C for this function (without includes and export directives):

  char *
  func_equals (const char *func_name, unsigned int argc, char **argv)
  {
      char *result = NULL;

      if (strcmp(argv[0], argv[1]) == 0) {
          result = gmk_alloc(strlen(argv[0]) + 1); /* not handling failure for simplicity */
          strcpy(result, argv[0]);
      }
    
      return result;
  }
This can be done with a macro but it's ugly and verbose. Macros also slow makefile parsing a lot and for a large build like e.g. an operating system this makes a big difference - it's a penalty you pay every time you run "make" even if you only changed 1 file.

There are plenty of things you cannot do with macros too. $(shell) is a getout card but it drastically slows down large makefiles.

Your module has a setup function which gets called when it's loaded and this adds the function into gmake:

  int
  equals_gmk_setup (const gmk_floc *flocp)
  {
      gmk_add_function ("equals", func_equals, 2, 2, GMK_FUNC_DEFAULT);
      return 1;
  }
Things that are hard/slow to do with macros like arithmetic - comparing, adding and so on are even better candidates. A hash function is great for generating intermediate target names that aren't too long for the filesystem.

My favorite one that I've done is embedding a python interpreter into make - this is very convenient as it's MUCH faster than running a process from $(shell) and it keeps state between uses which can be useful.

bandrami

GNU Make also embeds GNU Guile, a criminally underused feature:

https://www.gnu.org/software/make/manual/html_node/Guile-Int...

o11c

In practice, Guile is usually not compiled in. Whereas I've never seen a version of make without `load` and its supporting infrastructure.

bandrami

Debian gives you the option, with make and make-guile equivalent packages. IIRC Slackware simply compiles it in (guile already being there) and Fedora/RHEL leave it out entirely.

kazinator

It is criminally under-integrated!

The only interface you get into the make internals from Guile is a function to expand a make expression, and a function to eval a makefile fragment.

These interfaces only encourage the use of Guile for nothing more than make metaprogramming, an area where more power is not needed.

Imagine if Guile access to the rules as data structures or something. And the graph of targets to be updated and what not.

Imagine if Guile could be used, say, to override the logic by which a target is considered out of date with respect to its prerequisites.

.

nrclark

100% agree. With the current API, there's no real advantage to using Guile over a C extension (other than the choice of language). If the Guile interface could hook into Make's dependency graph, it would be huge game-changer. But as it is, the Guile interface is basically a fancy macro processor.

The Guile interface can expand Makefile expressions into values, and can process/evaluate Makefile statements. But there's no way (that I've found) to do something like "remove this dependency from target X", ask "what dependencies does X currently have?", or ask "do you think X is currently up-to-date?".

akoboldfrying

>Imagine if Guile could be used, say, to override the logic by which a target is considered out of date with respect to its prerequisites.

That is exactly what I was recently hoping for.

Make-as-library is such a compelling idea that I feel like it must have already been done, but I searched for something like this recently and the closest I found was Java's Ant, which gets the as-library part but sadly has no concept of "target is already up-to-date"...

srik

TIL thank you!

bandrami

I sometimes wonder if we would even have autotools or cmake if people just knew about this one simple trick

jhoechtl

Not for Windows

dima55

That's great. Thanks for pointing it out.

t43562

Delighted! :-) Glad someone found it a help

davemp

I’ve written a fair amount of Makefiles and bounced off of cmake. Recently I’ve started using zig to build some C++ projects and will not be switching back.

Having your build tool just be a library in a good general purpose language is the right move. Why use unergonomic hacks like the OP when you can use a sane language? My build.zig files have LSP completions and similar syntax (or the same) as what I’m building.

I put make solidly in the pile of tools that are only still around because of network effects. We’d have switched to something better if it weren’t defacto installed by every distro and had to make justifications to sys admins to install alternatives.

aeonik

Same reason I like Clojure tools.build. Any other way feels a little ridiculous to do it any other way.

null

[deleted]

einpoklum

Well, many of us certainly aren't happy living with the annoying syntax and arcane customs of CMake. But - it does get the job done, and incorporates large amounts of arcane knowledge, multiplied over numerous platforms - so that you don't have to. Can I get the same from a Zig-based build system, or build system generator? Can you perhaps link to some comparative review of using zig for building, with the use of CMake?

davemp

I don’t have a review, but here’s a significant project using it in a complicated cross platform build with different systems dependencies: https://github.com/raysan5/raylib/blob/master/build.zig

They also have a cmakelists.txt and pile of other cmake stuff to compare against: https://github.com/raysan5/raylib/tree/master/cmake

One of the nicer things is that if you’re working with less technical folks, they only need to download the zig binary because it bundles the entire toolchain. Real nice when on corporate windows systems.

einpoklum

> they only need to download the zig binary because it bundles the entire toolchain.

But that can't be possible... neither in principle nor in practice, because each projects needs a different toolchain. Different languages, different tools, different target platforms etc.

rkangel

I have written some large build systems entirely in Make. More complex things tend to rely on templates, but you can build arbitrary things, with two main limitations:

The error messages are awful, particularly if using templates. "Unexpected separator. Stop" is a classic, with no indication where in your 2k lines of Make it might be.

You can't have file or folder names with spaces in (usually including any parent folder to where your code is checked out). A "list" in Make is a series of strings separated by spaces. There are various workarounds that people suggest, but none of them work consistently across platforms. You just have to avoid spaces. At least this is less bad since Windows stopped using "Documents and Settings" for "home" folders.

dima55

GNU Make now has a debugger (`apt install remake`) that eases your first pain point a lot

bonzini

Even then the problem with doing complicated stuff in Make is that it's very hard to reproduce the environment that triggered the bug in the first place.

I came to the conclusion that you need to treat all of the build system as a linear process, which in Make would mean for example not using "=" at all except to define functions, only use ":=". With this kind of discipline I never really needed a debugger, but really Make is not the right language to write complex logic.

Personally I am a fan of (and contributor to) Meson. It's not perfect but it strikes a good balance between what is in the basic package and what you can do in your build script, and by keeping the build phases separate it really helps with keeping things understandable. The lack of functions can be annoying (and in general I wish it could use Starlark as the language), but it doesn't hurt if you follow the same principle and treat the build script as a data flow process, with each phase producing data structures for the next one. So I think it's generally a good principle to follow.

jgrahamc

I guess this is here because it's been 20 years and I blogged about it on Monday: https://blog.jgc.org/2025/02/twenty-years-of-gnu-make-standa...

beardyw

Make is just the epitome of software development:

Started as a simple idea

Required more sophistication

Became something no one person really understands

dima55

Did you try reading the manual?

rixed

Can't find it on youtube, link?

gpderetta

sarcasm?

RegW

Certainly not! That would be a faux pas.

high_na_euv

When software requires you to read manual, then it is strong hint that it has poor UI UX

Like, you dont read web browser manual to use it, even when using advanced features like debugger or dev console (advanced in compare to non-computer person)

armitron

Make is a power tool and power tools require effort to fully understand and master (though the base case in Make is surprisingly simple). It also has great documentation (which is something newer generations either don't appreciate or don't care about).

jcarrano

The manual has everything and is not long. It is actually very concise, but with the caveat that within each page you have to read everything. Every sentence of the manual has important information.

bch

> The GNU Make Standard Library (GMSL) is […] released under the BSD License.

That’s mildly interesting.

AceJohnny2

The GMSL is a godsend for those of us stuck on GNU Make 3.81 for... "reasons"

("reasons" being on macOS and limited to Xcode Command-Line Tools, which provides a number of GNU tools frozen to the last version that's GPLv2, before GPLv3.

Incidentally, that's also why macOS switched to Zsh by default, because Apple was tired of backporting security fixes to their Bash 3.2.57

/rant)

jcarrano

I can't even describe how much frustration this caused me when I worked at the RIOT project. macOS was by far the most problematic development platform to support. Even Windows was far friendlier since it has WSL which is officially supported.

AceJohnny2

In most situations (not mine), you can likely depend on MacPorts, Homebrew, or Nix to provide more up-to-date version of the tools you need that what Xcode provides. In that way, it's similar to WSL in that you can augment your environment to get the proper Unix tools you expect.

throwfgtpwd234

OP FYI: US copyright law doesn't recognize or require a range of years, only the date of first publication. Many organizations have decided to omit (the) year(s) altogether. https://blog.ntpsec.org/2020/02/15/copyright-year.html

nemoniac

Check the first comment on the linked page for counterpoint.

Also note that copyright laws exist outside the US and may differ.

jgrahamc

Good to know. I tend to use them as markers of "I started working on this in year XXXX and I last worked on it in year YYYY".

mubou

Correct me if I'm wrong, but I don't think the copyright statement actually has any legal effect anymore (Berne Convention of 1886 / 1989 for the US) so it doesn't really matter if there's a year or not. I think it's just informative.

MayeulC

One of my pet peeves with make is that it handles special characters in filenames (space, semicolon) very badly. Would this library help with that?

Some time ago, I tried to convert a music library, and ended up bulk renaming the files before and after running my makefile.

p4bl0

Okay who will be doing this year's Advent of Code in GNU Make?

throwfgtpwd234

What we really need is a C to GNU Make transpiler written in C just so it can translate itself.

phtrivier

But what system would you to build that ?

throwfgtpwd234

GNU Make and GCC, of course.

shakna

I wonder how thread-safe the memoisation and/or ALists are? Make's version of parralel processing is a very fun little thing, but has a few quirks around recursion limits that can bite you when going off the beaten path.

[0] https://www.gnu.org/software/make/manual/html_node/Options_0...

m463

Why doesn't someone just build good syntax into make itself?

just put some coded comment at the top of the file like "#makev2" and below have variables, arrays, lists, ignore tabs vs spaces, etc