8 ms·

Make is awesome. I have always loved make, and got really good with some of its magic. After switching to Java years ago, we collectively decided, "platform ind

Make is awesome. I have always loved make, and got really good with some of its magic. After switching to Java years ago, we collectively decided, "platform independent tools are better", and then we used ant. Man was ant bad, but hey! It was platform independent. Then we started using maven, and man, maven is ridiculously complex, especially adding custom tasks, but at least it was declarative. After getting into Rust, I have to say, Cargo got the declarative build just right. But then, for some basic scripts I decided to pick Make back up. And I wondered, why did we move away from this? It's so simple and straightforward. My suggestion, like others are saying, is keep it simple. Try and make declarative files, without needing to customize to projects. I do wish Make had a platform independent strict mode, because this is still an issue if you want to support different Unixes and Windows. p.s. I just thought of an interesting project. Something like oh-my-zsh for common configs.

cperciva 9y ago
make does have a platform independent strict mode. Unfortunately the ".POSIX:" mode is sufficiently limited that you won't want to use it for anything you're writing by hand.
- bluejekyll 9y ago
  Wow. I didn't realize this. Does it support Windows, without Linux etc installed?
  - mauvehaus 9y ago
    Don't know if there's a Win32 build of GNU make, but Microsoft has nmake. I haven't written a Makefile for it in years, but I have a hard time imagining there being much portability between the two. Not in the Makefile stucture, but rather in the commands it invokes to actually build targets.
  - cperciva 9y ago
    I'd guess that nmake is POSIX-compliant (or close to it), simply because the POSIX requirements are so minimal that it would take quite a bit of effort to avoid being POSIX compliant.
  - ksherlock 9y ago
    msys2 / cygnus, etc have GNU make for windows.
sitkack 9y ago
Make should have included something like tcl, or shipped its own tcl and its own os/posix libs. It is very easy for makefiles to become tied to a particular OS/Distribution/dev environment.
- chubot 9y ago
  GN Make 4.0 actually has Guile Scheme. This is pretty recent and I haven't seen it used yet. If anyone has seen it used, I'd be interested. https://www.gnu.org/software/make/manual/html_node/Guile-Integration.html https://www.gnu.org/software/make/manual/html_node/Guile-Int... https://jaxenter.com/gnu-make-4-0-adds-guile-output-sync-breaks-fewer-things-2-106859.html https://jaxenter.com/gnu-make-4-0-adds-guile-output-sync-bre... FWIW I wrote about how Make, shell, and awk heavily overlap in functionality here: http://www.oilshell.org/blog/2016/11/14.html http://www.oilshell.org/blog/2016/11/14.html This probably won't happen for quite a long time, but I'd like to expand my Oil shell to have the functionality of Make. On the one hand, it's kind of ironic that you're asking for Tcl, when shell is Turing complete and already such an integral part of Make (every line of the Makefile spawns /bin/sh). On the other hand, I understand that shell is a language with many sharp edges and most people dislike it. The point of Oil is to get rid of the sharp edges, and then maybe shell can take the place of Tcl/Guile. It seems a little ridiculous to write build scripts in make, shell, and guile, all of which are Turing-complete (not to mention Awk or Perl, which often show up). And I don't actually think Lisp/Scheme are very good languages for Unix-like text processing and syscalls/OS integration.
  - sitkack 9y ago
    What happens when /bin/sh is dash or bash? I despise /bin/sh, it is basically PHP. There isn't a terrible amount of basic functionality that would enable makefiles to cross platform (even cross distribution would be nice). Interacting with files, file metadata, processes, exit codes, etc. Absolutely love your oilshell posts. Keep it up. I think a concatenative language would be great as the embedded logic for Make, but a Lisp would also work.
    - chubot 9y ago
Rusky 9y ago
I do like the straightforwardness of Make. But it doesn't do quite enough for it to be simple to use for C or C++ programs. The simplest generic Makefile I can come up with that handles header file dependencies correctly is 10-20 lines of relatively complex interaction with the compiler. But then again maybe that's just an argument against C and C++'s compilation model. :)
- ajross 9y ago
  To be fair, dependency tracking is properly a function of the compiler, you can't do it in make alone without the ability to parse the language. And it's not 10-20 lines. GCC and clang both support the -M family of arguments that do this for you. It's a matter of running it to generate some sort of dependency file and including it in the makefile. Yes, that's annoying and definitely a problem with the inclusion-based dependency model of C. But really it's not such a big deal.
  - Rusky 9y ago
    Right, I was referring to adding the right -M arguments, including the generated .d files, and handling the edge cases with adding/removing files to the build. Overall the minimal Makefile I copy-paste into every new C project is about that size, so I suppose 10-20 lines includes a few other things as well.
  - lifthrasiir 9y ago
    > It's a matter of running it to generate some sort of dependency file and including it in the makefile. This is not as simple as it sounds. Make has a fundamental limitation that dependencies cannot be generated on the fly, and current workarounds for dependency-generating dependencies are very messy [1]. [1] http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ http://make.mad-scientist.net/papers/advanced-auto-dependenc...
    - wruza 9y ago
      >Although it’s simple, there are serious problems with this method. First and foremost is that dependencies are only rebuilt when the user explicitly requests it; if the user doesn’t run make depend regularly they could become badly out-of-date and make will not properly rebuild targets. Thus, we cannot say this is seamless and accurate. Not so fundamental, if you quickly make depend after changing includes. Why is that messy? I never got that "buy magic automation, sell simplicity" trading. Deps changed, deps have to be updated. Once updated, they just work.
JustSomeNobody 9y ago
I sometimes think we developers collectively gravitate towards complexity just to feel smart.
maxlybbert 9y ago
POSIX even has a number of implicit rules that make should recognize ( http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html#tag_04_84_13_03 http://pubs.opengroup.org/onlinepubs/009695399/utilities/mak... ). The real problem I have is that make generally relies on shell commands like cp, so there's no truly cross-platform (e.g., Windows and POSIX) way to copy files around in a makefile. I guess you could build your own utility, use it, and delete it when you're finished building. I've actually resorted to using ExtUtils::Command ( http://perldoc.perl.org/ExtUtils/Command.html http://perldoc.perl.org/ExtUtils/Command.html ).
valarauca1 9y ago
Did you enjoy build.rs?
bhaak 9y ago
How can Ant be bad? It's just Make in XML ... ;-) But because it is Make written in Java with a XML syntax, it has inherently the same problems. Fun fact: They had for years a makefile rant on their home page which boilt down to "Ant was invented because its developer couldn't make Makefiles work as his editor didn't properly show tabs vs spaces": https://web.archive.org/web/20100203102803/http://ant.apache.org:80/ https://web.archive.org/web/20100203102803/http://ant.apache...
- AstralStorm 9y ago
  Ant is actually a different beast, it is more declarative than procedural Makefile language. Still ugly and terrible and limiting.
  - bhaak 9y ago
    How is it more declarative than the Makefile language? You declare targets and dependencies and the steps within are target a executed procedurally in sequence. This sentence is 100% true for both Ant and Make. Ugly, yes. It was developed during the times when everything had to be XML. But also Makefiles don't win a beauty contest. Terrible. Maybe, but not worse than trying to write portable Makefile for something non-trivial (e.g. libraries). Limiting? In what way? You are encouraged to use the supplied tasks which cover a lot. Creating new tasks would be done in the language you programming. You can still execute any arbitrary command if you really want to.
    - AstralStorm 9y ago
      In ant, to declare a target for any no direct code generator is a royal pain. Even worse than in Make. Ant is declarative in that you do not directly refer to files except in tasks that directly handle files. You cannot say that phony task x depends on file y.
- mannykannot 9y ago
  I always suspected that ant was written by people who didn't first take a look at what already existed. Make's use of tabs was a mistake, but not a fatal one.

cperciva 9y ago

make does have a platform independent strict mode. Unfortunately the ".POSIX:" mode is sufficiently limited that you won't want to use it for anything you're writing by hand.

bluejekyll 9y ago
Wow. I didn't realize this. Does it support Windows, without Linux etc installed?
- mauvehaus 9y ago
  Don't know if there's a Win32 build of GNU make, but Microsoft has nmake. I haven't written a Makefile for it in years, but I have a hard time imagining there being much portability between the two. Not in the Makefile stucture, but rather in the commands it invokes to actually build targets.
- cperciva 9y ago
  I'd guess that nmake is POSIX-compliant (or close to it), simply because the POSIX requirements are so minimal that it would take quite a bit of effort to avoid being POSIX compliant.
- ksherlock 9y ago
  msys2 / cygnus, etc have GNU make for windows.

sitkack 9y ago

Make should have included something like tcl, or shipped its own tcl and its own os/posix libs. It is very easy for makefiles to become tied to a particular OS/Distribution/dev environment.

chubot 9y ago
GN Make 4.0 actually has Guile Scheme. This is pretty recent and I haven't seen it used yet. If anyone has seen it used, I'd be interested. https://www.gnu.org/software/make/manual/html_node/Guile-Integration.html https://www.gnu.org/software/make/manual/html_node/Guile-Int... https://jaxenter.com/gnu-make-4-0-adds-guile-output-sync-breaks-fewer-things-2-106859.html https://jaxenter.com/gnu-make-4-0-adds-guile-output-sync-bre... FWIW I wrote about how Make, shell, and awk heavily overlap in functionality here: http://www.oilshell.org/blog/2016/11/14.html http://www.oilshell.org/blog/2016/11/14.html This probably won't happen for quite a long time, but I'd like to expand my Oil shell to have the functionality of Make. On the one hand, it's kind of ironic that you're asking for Tcl, when shell is Turing complete and already such an integral part of Make (every line of the Makefile spawns /bin/sh). On the other hand, I understand that shell is a language with many sharp edges and most people dislike it. The point of Oil is to get rid of the sharp edges, and then maybe shell can take the place of Tcl/Guile. It seems a little ridiculous to write build scripts in make, shell, and guile, all of which are Turing-complete (not to mention Awk or Perl, which often show up). And I don't actually think Lisp/Scheme are very good languages for Unix-like text processing and syscalls/OS integration.
- sitkack 9y ago
  What happens when /bin/sh is dash or bash? I despise /bin/sh, it is basically PHP. There isn't a terrible amount of basic functionality that would enable makefiles to cross platform (even cross distribution would be nice). Interacting with files, file metadata, processes, exit codes, etc. Absolutely love your oilshell posts. Keep it up. I think a concatenative language would be great as the embedded logic for Make, but a Lisp would also work.
  - chubot 9y ago

Rusky 9y ago

I do like the straightforwardness of Make. But it doesn't do quite enough for it to be simple to use for C or C++ programs. The simplest generic Makefile I can come up with that handles header file dependencies correctly is 10-20 lines of relatively complex interaction with the compiler. But then again maybe that's just an argument against C and C++'s compilation model. :)

ajross 9y ago
To be fair, dependency tracking is properly a function of the compiler, you can't do it in make alone without the ability to parse the language. And it's not 10-20 lines. GCC and clang both support the -M family of arguments that do this for you. It's a matter of running it to generate some sort of dependency file and including it in the makefile. Yes, that's annoying and definitely a problem with the inclusion-based dependency model of C. But really it's not such a big deal.
- Rusky 9y ago
  Right, I was referring to adding the right -M arguments, including the generated .d files, and handling the edge cases with adding/removing files to the build. Overall the minimal Makefile I copy-paste into every new C project is about that size, so I suppose 10-20 lines includes a few other things as well.
- lifthrasiir 9y ago
  > It's a matter of running it to generate some sort of dependency file and including it in the makefile. This is not as simple as it sounds. Make has a fundamental limitation that dependencies cannot be generated on the fly, and current workarounds for dependency-generating dependencies are very messy [1]. [1] http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ http://make.mad-scientist.net/papers/advanced-auto-dependenc...
  - wruza 9y ago
    >Although it’s simple, there are serious problems with this method. First and foremost is that dependencies are only rebuilt when the user explicitly requests it; if the user doesn’t run make depend regularly they could become badly out-of-date and make will not properly rebuild targets. Thus, we cannot say this is seamless and accurate. Not so fundamental, if you quickly make depend after changing includes. Why is that messy? I never got that "buy magic automation, sell simplicity" trading. Deps changed, deps have to be updated. Once updated, they just work.

JustSomeNobody 9y ago

I sometimes think we developers collectively gravitate towards complexity just to feel smart.

maxlybbert 9y ago

POSIX even has a number of implicit rules that make should recognize ( http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html#tag_04_84_13_03 http://pubs.opengroup.org/onlinepubs/009695399/utilities/mak... ). The real problem I have is that make generally relies on shell commands like cp, so there's no truly cross-platform (e.g., Windows and POSIX) way to copy files around in a makefile. I guess you could build your own utility, use it, and delete it when you're finished building. I've actually resorted to using ExtUtils::Command ( http://perldoc.perl.org/ExtUtils/Command.html http://perldoc.perl.org/ExtUtils/Command.html ).

valarauca1 9y ago

Did you enjoy build.rs?

bhaak 9y ago

How can Ant be bad? It's just Make in XML ... ;-) But because it is Make written in Java with a XML syntax, it has inherently the same problems. Fun fact: They had for years a makefile rant on their home page which boilt down to "Ant was invented because its developer couldn't make Makefiles work as his editor didn't properly show tabs vs spaces": https://web.archive.org/web/20100203102803/http://ant.apache.org:80/ https://web.archive.org/web/20100203102803/http://ant.apache...

AstralStorm 9y ago
Ant is actually a different beast, it is more declarative than procedural Makefile language. Still ugly and terrible and limiting.
- bhaak 9y ago
  How is it more declarative than the Makefile language? You declare targets and dependencies and the steps within are target a executed procedurally in sequence. This sentence is 100% true for both Ant and Make. Ugly, yes. It was developed during the times when everything had to be XML. But also Makefiles don't win a beauty contest. Terrible. Maybe, but not worse than trying to write portable Makefile for something non-trivial (e.g. libraries). Limiting? In what way? You are encouraged to use the supplied tasks which cover a lot. Creating new tasks would be done in the language you programming. You can still execute any arbitrary command if you really want to.
  - AstralStorm 9y ago
    In ant, to declare a target for any no direct code generator is a royal pain. Even worse than in Make. Ant is declarative in that you do not directly refer to files except in tasks that directly handle files. You cannot say that phony task x depends on file y.
mannykannot 9y ago
I always suspected that ant was written by people who didn't first take a look at what already existed. Make's use of tabs was a mistake, but not a fatal one.