15 ms·

I think the reason make is both so controversial and also long-lived is that despite how everyone thinks of it, it isn't really a build tool. It actually doesn'

I think the reason make is both so controversial and also long-lived is that despite how everyone thinks of it, it isn't really a build tool. It actually doesn't know anything at all about how to build C, C++, or any other kind of code. (I know this is obvious to those of us that know make, but I often get the impression that a lot of people think of make as gradle or maven for C, which it really isn't.) It's really a workflow automation tool, and the UX for that is actually pretty close to what you would want. You can pretty trivially just copy tiresome sequences of shell commands that you started out typing manually into a Makefile and automate your workflow really easily without thinking too much. Of course that's what shell scripts are for too, but make has an understanding of file based dependencies that lets you much more naturally express the automated steps in a way that's a lot more efficient to run. A lot of more modern build tools mix up the workflow element with the build element (and in some cases with packaging and distribution as well), and so they are "better than make", but only for a specific language and a specific workflow.

sebcat 9y ago
> It actually doesn't know anything at all about how to build C, C++, or any other kind of code. I guess it depends on how you define "know", but there are implicit rules. $ cat foo.c #include <stdio.h> int main() { printf("Hello\n"); return 0; } $ cat Makefile foo: foo.c $ make cc -O2 -pipe foo.c -o foo $ ./foo Hello
- peterwwillis 9y ago
  Yeah. There is a metric crap-ton of the design of Make that is solely for the purpose of compiling and linking and document processing. That's actually part of what makes it annoying to use it for projects other than C or C++, when you don't need to compile or transform or depend on different formats.
  - rschloming 9y ago
    The core of make is really just a control flow model that understands file dependencies as a first class thing, and permits arbitrary user supplied actions to be specified to update those files. All those default rules around how to handle C files are really more like a standard library and can be easily overridden as desired. IMHO what makes it annoying for projects other than C or C++ is that there isn't an equivalent portion of makes "standard library" that applies to e.g. java, but this is largely because java went down a different path to develop its build ecosystem. In an alternate reality java tooling might have been designed to work well with make, and then make would have a substantial builtin knowledge base around how to work with java artifacts as well as having a really nice UX for automating custom workflows, but instead java went down the road of creating monolithic build tooling and for a long time java build tooling really sucked at being extensible for custom workflows.
    - coliveira 9y ago
      The thing about Java is that it has its own dependency system embedded in the compiler. This design decision made it difficult to integrate with a tool like make.
      - rschloming 9y ago
        I don't think having dependencies built into the language and/or compiler means it needs to be difficult to integrate with something like make. In fact gcc has dependency analysis built into it. It just knows how to output that information in a simple format that make can then consume. I feel like this choice has more to do with early java culture and/or constraints as compared to unix/linux. With "the unix way" it is really common to solve a problem by writing two separate programs that are loosely coupled by a simple text based file format. When done well, this approach has a lot of the benefits of well done microservices-style applications built today. By contrast, (and probably for a variety of reasons) this approach was always very rare in early java days. It seemed for a while like the norm was to rewrite everything in java and run it all in one giant JVM in order to avoid JVM startup overhead. ;-) The upshot being you often ended up with a lot more monolithic/tightly coupled designs in Java. (I think this is less true about Java today.)
  - LukeShu 9y ago
    > There is a metric crap-ton of the design of Make that is solely for the purpose of compiling and linking and document processing. Not really. The bit being pointed out here certainly isn't. It's not any special design going on, it's just a built-in library of rules and variables for C/C++/Pascal/Fortran/Modula-2/Assembler/TeX. These rules are no different than if you had typed them in to the Makefile yourself. And if you don't like them, you can say --no-builtin-rules --no-builtin-variables. The only actual bit of C-specific design I can think of is .LIBPATTERNS library searching.
- dima55 9y ago
  Fun fact: your Makefile above is redundant. You can delete it entirely, and the implicit rules you're using here continue to work just fine.
  - sebcat 9y ago
    That doesn't work for me. Tried with empty Makefile, no Makefile, with make (PMake) and gmake (GNU Make).
    - mhei 9y ago
      Try "make foo" instead of "make"
      - sebcat 9y ago
        Ah, that works!
    - dima55 9y ago
      Don't know why that would be. I'm using GNU Make 4.1, but this has worked for years and years as far as I knew. Not a particularly useful feature, so I it doesn't really matter, but you messed up my fun fact. dima@fatty:/tmp$ mkdir dir dima@fatty:/tmp$ cd dir dima@fatty:/tmp/dir$ touch foo.c dima@fatty:/tmp/dir$ make -n foo cc foo.c -o foo dima@fatty:/tmp/dir$ make --version GNU Make 4.1 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
      - therein 9y ago
        I had fun learning about that.
    - klmr 9y ago
      Then you did something wrong — it definitely works with GNU make (can’t speak for PMake): https://asciinema.org/a/zVu7sYyh7lQZTNAgAsbKUmocr https://asciinema.org/a/zVu7sYyh7lQZTNAgAsbKUmocr
lisper 9y ago
> It's really a workflow automation tool, That's true. > and the UX for that is actually pretty close to what you would want. That is so not true. Make has deeply woven into it the assumption that the product of workflows are files, and that the way you can tell the state of a file is by its last modification date. That's often true for builds (which is why make works reasonably well for builds), but often not true for other kinds of workflows. But regardless of that, a tool that makes a semantic distinction between tabs and spaces is NEVER the UX you want unless you're a masochist.
- derefr 9y ago
  > Make has deeply woven into it the assumption that the product of workflows are files, and that the way you can tell the state of a file is by its last modification date. I've always wondered whether Make would be seen as less of a grudging necessity, and more of an elegant panacea, if operating systems had gone the route of Plan 9, where everything is—symbolically—a file, even if it's not a file in the sense of "a byte-stream persisted on disk." Or, to put that another way: have you ever considered writing a FUSE filesystem to expose workflow inputs as readable files, and expect outputs as file creation/write calls—and then just throw Make at that?
  - lisper 9y ago
    > everything is—symbolically—a file How are you going to make the result of a join in a relational database into a file, symbolically or otherwise?
    - fiatjaf 9y ago
      You would probably need another query language, but that would come with time, after people had gotten used to the idea. With that said, there are NoSQL databases these days whose query language is easily expressed as file paths. CouchDB, for example.
    - com2kid 9y ago
      > How are you going to make the result of a join in a relational database into a file, symbolically or otherwise? A file that represents the temporary table that has been created. Naming it is harder, unless the SQL query writer was feeling nice and verbose.
deleted 9y ago
[deleted]

sebcat 9y ago

> It actually doesn't know anything at all about how to build C, C++, or any other kind of code. I guess it depends on how you define "know", but there are implicit rules. $ cat foo.c #include <stdio.h> int main() { printf("Hello\n"); return 0; } $ cat Makefile foo: foo.c $ make cc -O2 -pipe foo.c -o foo $ ./foo Hello

peterwwillis 9y ago
Yeah. There is a metric crap-ton of the design of Make that is solely for the purpose of compiling and linking and document processing. That's actually part of what makes it annoying to use it for projects other than C or C++, when you don't need to compile or transform or depend on different formats.
- rschloming 9y ago
  The core of make is really just a control flow model that understands file dependencies as a first class thing, and permits arbitrary user supplied actions to be specified to update those files. All those default rules around how to handle C files are really more like a standard library and can be easily overridden as desired. IMHO what makes it annoying for projects other than C or C++ is that there isn't an equivalent portion of makes "standard library" that applies to e.g. java, but this is largely because java went down a different path to develop its build ecosystem. In an alternate reality java tooling might have been designed to work well with make, and then make would have a substantial builtin knowledge base around how to work with java artifacts as well as having a really nice UX for automating custom workflows, but instead java went down the road of creating monolithic build tooling and for a long time java build tooling really sucked at being extensible for custom workflows.
  - coliveira 9y ago
    The thing about Java is that it has its own dependency system embedded in the compiler. This design decision made it difficult to integrate with a tool like make.
    - rschloming 9y ago
      I don't think having dependencies built into the language and/or compiler means it needs to be difficult to integrate with something like make. In fact gcc has dependency analysis built into it. It just knows how to output that information in a simple format that make can then consume. I feel like this choice has more to do with early java culture and/or constraints as compared to unix/linux. With "the unix way" it is really common to solve a problem by writing two separate programs that are loosely coupled by a simple text based file format. When done well, this approach has a lot of the benefits of well done microservices-style applications built today. By contrast, (and probably for a variety of reasons) this approach was always very rare in early java days. It seemed for a while like the norm was to rewrite everything in java and run it all in one giant JVM in order to avoid JVM startup overhead. ;-) The upshot being you often ended up with a lot more monolithic/tightly coupled designs in Java. (I think this is less true about Java today.)
- LukeShu 9y ago
  > There is a metric crap-ton of the design of Make that is solely for the purpose of compiling and linking and document processing. Not really. The bit being pointed out here certainly isn't. It's not any special design going on, it's just a built-in library of rules and variables for C/C++/Pascal/Fortran/Modula-2/Assembler/TeX. These rules are no different than if you had typed them in to the Makefile yourself. And if you don't like them, you can say --no-builtin-rules --no-builtin-variables. The only actual bit of C-specific design I can think of is .LIBPATTERNS library searching.
dima55 9y ago
Fun fact: your Makefile above is redundant. You can delete it entirely, and the implicit rules you're using here continue to work just fine.
- sebcat 9y ago
  That doesn't work for me. Tried with empty Makefile, no Makefile, with make (PMake) and gmake (GNU Make).
  - mhei 9y ago
    Try "make foo" instead of "make"
    - sebcat 9y ago
      Ah, that works!
  - dima55 9y ago
    Don't know why that would be. I'm using GNU Make 4.1, but this has worked for years and years as far as I knew. Not a particularly useful feature, so I it doesn't really matter, but you messed up my fun fact. dima@fatty:/tmp$ mkdir dir dima@fatty:/tmp$ cd dir dima@fatty:/tmp/dir$ touch foo.c dima@fatty:/tmp/dir$ make -n foo cc foo.c -o foo dima@fatty:/tmp/dir$ make --version GNU Make 4.1 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
    - therein 9y ago
      I had fun learning about that.
  - klmr 9y ago
    Then you did something wrong — it definitely works with GNU make (can’t speak for PMake): https://asciinema.org/a/zVu7sYyh7lQZTNAgAsbKUmocr https://asciinema.org/a/zVu7sYyh7lQZTNAgAsbKUmocr

lisper 9y ago

> It's really a workflow automation tool, That's true. > and the UX for that is actually pretty close to what you would want. That is so not true. Make has deeply woven into it the assumption that the product of workflows are files, and that the way you can tell the state of a file is by its last modification date. That's often true for builds (which is why make works reasonably well for builds), but often not true for other kinds of workflows. But regardless of that, a tool that makes a semantic distinction between tabs and spaces is NEVER the UX you want unless you're a masochist.

derefr 9y ago
> Make has deeply woven into it the assumption that the product of workflows are files, and that the way you can tell the state of a file is by its last modification date. I've always wondered whether Make would be seen as less of a grudging necessity, and more of an elegant panacea, if operating systems had gone the route of Plan 9, where everything is—symbolically—a file, even if it's not a file in the sense of "a byte-stream persisted on disk." Or, to put that another way: have you ever considered writing a FUSE filesystem to expose workflow inputs as readable files, and expect outputs as file creation/write calls—and then just throw Make at that?
- lisper 9y ago
  > everything is—symbolically—a file How are you going to make the result of a join in a relational database into a file, symbolically or otherwise?
  - fiatjaf 9y ago
    You would probably need another query language, but that would come with time, after people had gotten used to the idea. With that said, there are NoSQL databases these days whose query language is easily expressed as file paths. CouchDB, for example.
  - com2kid 9y ago
    > How are you going to make the result of a join in a relational database into a file, symbolically or otherwise? A file that represents the temporary table that has been created. Naming it is harder, unless the SQL query writer was feeling nice and verbose.

deleted 9y ago

[deleted]