5 ms·

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

VMG 13y ago
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.
- emmelaich 13y ago
  I often think how much better Make would have been with elisp or scheme syntax rather than extending it with shell.
opk 13y ago
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.
- mturmon 13y ago
  One starting place for some of these functions is: http://www.gnu.org/software/make/manual/html_node/Functions.html 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_002dLine.html 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.
vog 13y ago
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/ http://mxe.cc/ [2] https://github.com/mxe/mxe/blob/master/Makefile https://github.com/mxe/mxe/blob/master/Makefile
- mzs 13y ago
  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!
  - mturmon 13y ago
    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.
    - opk 13y ago
      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.
      - vog 13y ago
        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).
ajross 13y ago
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?

VMG 13y ago

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.

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

opk 13y ago

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.

mturmon 13y ago
One starting place for some of these functions is: http://www.gnu.org/software/make/manual/html_node/Functions.html 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_002dLine.html 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.

vog 13y ago

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/ http://mxe.cc/ [2] https://github.com/mxe/mxe/blob/master/Makefile https://github.com/mxe/mxe/blob/master/Makefile

mzs 13y ago
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!
- mturmon 13y ago
  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.
  - opk 13y ago
    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.
    - vog 13y ago
      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).

ajross 13y ago

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?