5 ms·

Using make gets quickly really ugly. I wrote many Makefiles in my life and if you have to try to stick to GNU Make. At least it provides some basic functional

by fafner 14y ago

Using make gets quickly really ugly. I wrote many Makefiles in my life and if you have to try to stick to GNU Make. At least it provides some basic functionality. But even that gets nasty quite soon when you need a simple thing like conditions with "and" or "or". If you have to write portable Makefiles ... well fsck. http://www.conifersystems.com/whitepapers/gnu-make/ http://www.conifersystems.com/whitepapers/gnu-make/ There were recent discussions about adding GNU Guile to GNU Make. I think this is a brilliant idea. Not only would a major GNU project not only use Guile. But it would make writing Makefiles much more enjoyable because you have a real programming language at hand.

eropple 14y ago
Personally, I don't want a programming language in my makefiles. Unless working in a very codified environment (Java and Maven, for example), I think it is vital to keep your build system as simple as you can. If I absolutely need nontrivial logic in my makefile, I would much, much rather be forced to call out to a script file (because it encourages not doing that). And if you insist on parking a programming language into it, it should probably be something with a reasonable amount of existing knowledge and users. I like Scheme, but unless the project was written in a Lisp I'd seriously question the judgment of anybody whacking Scheme into a build file multiple people had to work with and understand.
- __david__ 14y ago
  After using Rake (ruby with some dependency DSLish stuff) on a project for a solid year, I appreciate Make much more. Rake is too powerful and makes it too easy to keep a bunch of complex logic inside the Rakefile. Our project, left unchecked, turned the Rakefile into a pile of spaghetti. Make, on the other hand, being kind of crufty and inconvenient, encourages moving complex logic out of itself and into external scripts earlier than Rake. On top of that it encourages you to have reasonable interfaces to those scripts so that they fit back into the Makefile gracefully. So ironically, Make, by being obtuse, ends up encouraging better overall project build structure.
  - ufo 14y ago
    What sort of issue did you run into. I am wondering if its osmething that could be solved by better modularization/sandboxing or if its more fundamental problems.
    - __david__ 14y ago
      It's not a programming issue per se, it's a human issue. Rake provides a nice baseline for throwing all your quickie scripts into little functions that end up with reasonable (if basic) command line interfaces for free. Those quickie scripts inevitably grow more complicated as the project goes on (usually because the project itself gets more complicated over time) and before long you've outgrown Rake. Except that since Rake is just Ruby it tricks you into thinking you haven't outgrown it! I started noticing it when I was taking a bunch of time deciding in what order I should be putting the optional parameters to my Rake tasks such that it was most convenient to the user and spending way to much code validating those arguments and setting defaults when I realized that I could've written a script using 'optparse' that would easier to document, easier to use, and easier to write and modify. There's a graph you could make where the X axis is size of the script and the Y axis is complexity (or maybe "effort"). The Rake line, drawn on this graph, starts near 0,0 but climbs and a nice steep rate. Make starts at basically the same spot as Rake but climbs way faster. A standalone command-line script starts a bit higher on the Y axis, but is flatter over all. The point at which the Rake (or Make) and the script lines meet is where you should switch to a standalone script. With Make, this happens fairly early on when things are still relatively simple. So you convert your bash commands into a Ruby script and you end up better off in the long run. With Rake it happens so late that converting to a standalone script becomes a very large undertaking and nobody wants to do it (because it still works--why mess with it?). Over the long haul it becomes a pain point.
- wingo 14y ago
  You already have a programming language in your makefiles. http://okmij.org/ftp/Computation/#Makefile-functional http://okmij.org/ftp/Computation/#Makefile-functional
- ufo 14y ago
  I hear this sort of argument all the time (build systems, templating engines, config files, etc) and I'm not sure I agree with it anymore. Invariably people start adding features and you wnd up with horrible warty languages full of corner cases like make or shell.
  - CmdrKrool 14y ago
    Yeah, limitations like these are often just a red rag to hackers that naturally love the challenge of overcoming apparent limitations with ornate workarounds. See the gmsl library mentioned in the current top post for example, which I read a bit of while trying to get a handle on the Android NDK's build system; respect to jgrahamc for its cleverness but if you don't like Make in the first place, you're inclined to feel that more of it is bad and not good.
- fafner 14y ago
  GNU Make already is a programming language. It's just not a very good one. Wouldn't Scheme be helpful to your "don't write programs in Make"-attitude? I mean if only few people know scheme they'll be less likely to hack your Makefile.
udp 14y ago
The stupid thing is that conditions are supported just fine in BSD make, but the syntax is slightly different than GNU make. So you're forced to write for one or the other, and GNU make is more widely used - so makefiles end up being GNU make only, even though they don't require any GNU-specific features.
rdtsc 14y ago
Any thoughts on CMake for portable Makefile generation. It seems a lot projects use that.
- fafner 14y ago
  CMake is a great example on problems with DSLs. Simply not everybody is a good language designer. CMake uses a pretty horrible language and comes with its own kinds of strangeness. I have used it quite extensively and it's probably the way to go if you want to support MSVC. But I'm not really happy with it.
zwegner 14y ago
Here's a very simple but powerful build system by the author of that paper: http://code.google.com/p/make-py/ http://code.google.com/p/make-py/ It's just a single ~400 line python script. The only major feature that's missing IMO is hash-based rebuild detection, which is essential if you're using much auto-generated code.
- ycombobreaker 14y ago
  > The only major feature that's missing IMO is hash-based rebuild detection, which is essential if you're using much auto-generated code. I'm guessing that your goal here is to avoid a recompile if the auto-generated content did not change. This is not a problem for timestamp-based build tools if you add a single step: auto-generate your output to a temp file, and only replace the target with the temp file if the file shows a difference. The program `install` will do the 'copy iff file contents have changed' part for you, so it's really just two extra lines in the Makefile recipe.
  - zwegner 14y ago
    Interesting idea, I hadn't thought of that before. This only increases the complexity of the Makefile though, and for not much reason. Hashing can help in other circumstances (such as possibly skipping a linking step if the object files don't change), and it would really be much cleaner to have it as part of the build system. The last time I played around with generating code through make, it got real ugly real fast, and I don't think your 'install' trick will help much in that regard...
    - ycombobreaker 14y ago
      > ... for not much reason There's actually a good reason to do this, but it is an edge case. A timestamp-based build system can do a no-op check with very little I/O. A hash-based build system has to read all of the file contents in order to determine that nothing has changed. Depending on the latency and bandwidth of your storage, this can make a big difference in incremental builds.

by fafner 14y ago

eropple 14y ago

Personally, I don't want a programming language in my makefiles. Unless working in a very codified environment (Java and Maven, for example), I think it is vital to keep your build system as simple as you can. If I absolutely need nontrivial logic in my makefile, I would much, much rather be forced to call out to a script file (because it encourages not doing that). And if you insist on parking a programming language into it, it should probably be something with a reasonable amount of existing knowledge and users. I like Scheme, but unless the project was written in a Lisp I'd seriously question the judgment of anybody whacking Scheme into a build file multiple people had to work with and understand.

__david__ 14y ago
After using Rake (ruby with some dependency DSLish stuff) on a project for a solid year, I appreciate Make much more. Rake is too powerful and makes it too easy to keep a bunch of complex logic inside the Rakefile. Our project, left unchecked, turned the Rakefile into a pile of spaghetti. Make, on the other hand, being kind of crufty and inconvenient, encourages moving complex logic out of itself and into external scripts earlier than Rake. On top of that it encourages you to have reasonable interfaces to those scripts so that they fit back into the Makefile gracefully. So ironically, Make, by being obtuse, ends up encouraging better overall project build structure.
- ufo 14y ago
  What sort of issue did you run into. I am wondering if its osmething that could be solved by better modularization/sandboxing or if its more fundamental problems.
  - __david__ 14y ago
    It's not a programming issue per se, it's a human issue. Rake provides a nice baseline for throwing all your quickie scripts into little functions that end up with reasonable (if basic) command line interfaces for free. Those quickie scripts inevitably grow more complicated as the project goes on (usually because the project itself gets more complicated over time) and before long you've outgrown Rake. Except that since Rake is just Ruby it tricks you into thinking you haven't outgrown it! I started noticing it when I was taking a bunch of time deciding in what order I should be putting the optional parameters to my Rake tasks such that it was most convenient to the user and spending way to much code validating those arguments and setting defaults when I realized that I could've written a script using 'optparse' that would easier to document, easier to use, and easier to write and modify. There's a graph you could make where the X axis is size of the script and the Y axis is complexity (or maybe "effort"). The Rake line, drawn on this graph, starts near 0,0 but climbs and a nice steep rate. Make starts at basically the same spot as Rake but climbs way faster. A standalone command-line script starts a bit higher on the Y axis, but is flatter over all. The point at which the Rake (or Make) and the script lines meet is where you should switch to a standalone script. With Make, this happens fairly early on when things are still relatively simple. So you convert your bash commands into a Ruby script and you end up better off in the long run. With Rake it happens so late that converting to a standalone script becomes a very large undertaking and nobody wants to do it (because it still works--why mess with it?). Over the long haul it becomes a pain point.
wingo 14y ago
You already have a programming language in your makefiles. http://okmij.org/ftp/Computation/#Makefile-functional http://okmij.org/ftp/Computation/#Makefile-functional
ufo 14y ago
I hear this sort of argument all the time (build systems, templating engines, config files, etc) and I'm not sure I agree with it anymore. Invariably people start adding features and you wnd up with horrible warty languages full of corner cases like make or shell.
- CmdrKrool 14y ago
  Yeah, limitations like these are often just a red rag to hackers that naturally love the challenge of overcoming apparent limitations with ornate workarounds. See the gmsl library mentioned in the current top post for example, which I read a bit of while trying to get a handle on the Android NDK's build system; respect to jgrahamc for its cleverness but if you don't like Make in the first place, you're inclined to feel that more of it is bad and not good.
fafner 14y ago
GNU Make already is a programming language. It's just not a very good one. Wouldn't Scheme be helpful to your "don't write programs in Make"-attitude? I mean if only few people know scheme they'll be less likely to hack your Makefile.

udp 14y ago

The stupid thing is that conditions are supported just fine in BSD make, but the syntax is slightly different than GNU make. So you're forced to write for one or the other, and GNU make is more widely used - so makefiles end up being GNU make only, even though they don't require any GNU-specific features.

rdtsc 14y ago

Any thoughts on CMake for portable Makefile generation. It seems a lot projects use that.

fafner 14y ago
CMake is a great example on problems with DSLs. Simply not everybody is a good language designer. CMake uses a pretty horrible language and comes with its own kinds of strangeness. I have used it quite extensively and it's probably the way to go if you want to support MSVC. But I'm not really happy with it.

zwegner 14y ago

Here's a very simple but powerful build system by the author of that paper: http://code.google.com/p/make-py/ http://code.google.com/p/make-py/ It's just a single ~400 line python script. The only major feature that's missing IMO is hash-based rebuild detection, which is essential if you're using much auto-generated code.

ycombobreaker 14y ago
> The only major feature that's missing IMO is hash-based rebuild detection, which is essential if you're using much auto-generated code. I'm guessing that your goal here is to avoid a recompile if the auto-generated content did not change. This is not a problem for timestamp-based build tools if you add a single step: auto-generate your output to a temp file, and only replace the target with the temp file if the file shows a difference. The program `install` will do the 'copy iff file contents have changed' part for you, so it's really just two extra lines in the Makefile recipe.
- zwegner 14y ago
  Interesting idea, I hadn't thought of that before. This only increases the complexity of the Makefile though, and for not much reason. Hashing can help in other circumstances (such as possibly skipping a linking step if the object files don't change), and it would really be much cleaner to have it as part of the build system. The last time I played around with generating code through make, it got real ugly real fast, and I don't think your 'install' trick will help much in that regard...
  - ycombobreaker 14y ago
    > ... for not much reason There's actually a good reason to do this, but it is an edge case. A timestamp-based build system can do a no-op check with very little I/O. A hash-based build system has to read all of the file contents in order to determine that nothing has changed. Depending on the latency and bandwidth of your storage, this can make a big difference in incremental builds.