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

I'm being incredibly unimaginative today, but what's a good use-case for extending Make via scheme?


Some years ago I designed a Makefile-based build system [1] that uses many GNU Make features. If you write Makefiles on that level, you quickly notice that GNU Make's internal structure resembles Lisp quite a lot [2], e.g. you write $(filter xx,yy) which is very close to (filter xx yy). Also, you have other Lisp-like stuff like quoting, eval, and so on. Sometimes GNU Make really felt almost like Lisp, but with a slightly more cumbersome syntax and evaluation model.

So I often asked myself why they don't use Lisp directly. Now they almost do, which I find very consequent.

[1] http://mxe.cc/

[2] https://github.com/mxe/mxe/blob/master/Makefile


That's funny, I see what you are talking about, but I had a moment like that with make, but instead likened it to prolog instead in my head one evening!


I think Prolog is a much better analogy than Lisp. Like Prolog, the Makefile declares relationships, which go into a rule database, and then when you need to make something, the runtime scans the rules looking for what matches. This will imply other dependencies, which are satisfied recursively.


There are two separate stages with GNU make. The first is very lisp like with the functions like $(filter) and you use it to create all the rules for the second, more prolog like, stage. A simple Makefile would do nothing for the first stage because it'd all be static text instead of function calls.


Not only that. In the above mentioned MXE project, the $(...) functions also play a vital role on the "second stage": They create a huge, automatic set of rules and actions, based on a higher-level description that is given for each package via a bunch Make variables (some of which are multiline and contain actual commands for that package).


Being unreasonably optimistic, I hope for the replacement of a bunch of other cruft around the toolchain with Scheme.

Being realistic, I look forward to adding Scheme to the cruft.


I often think how much better Make would have been with elisp or scheme syntax rather than extending it with shell.


GNU make already has a number of functions for things like filtering a list for strings matching a pattern. There were many requests for additional functions. There's some sense to integrating guile rather than going further down the path of extending the macro/function language that GNU make essentially has.


One starting place for some of these functions is:

http://www.gnu.org/software/make/manual/html_node/Functions....

(note "foreach", "call", "eval") and:

http://www.gnu.org/software/make/manual/html_node/Multi_002d...

For instance, from the "call" documentation --

"The call function is unique in that it can be used to create new parameterized functions."

Sometimes these types of functions are really important, and you have to be creative to use the builtins to set up the dependencies you want. For instance, by combining "foreach" with "call" or "eval", you can dynamically create sets of rules. This can be quite powerful.

And you don't have to use make only for software compilation. You can use it to create more general-purpose data transformations. When you get a batch of new images, for example, you type "make", and it just recomputes all the derived data (but only what depends on the new stuff). I have done this, and it was very slick, but it tends to stress the existing function set.


The obvious example I can think of is autotools. If make had a built-in scheme 20 years ago, would we be suffering with the existing m4/shell monstrosity?




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

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

Search: