4 ms·

Make is great as a dependency resolution engine. For everything else, it is absolutely horrible. What I typically do is use make only for what it is good: as

Make is great as a dependency resolution engine. For everything else, it is absolutely horrible. What I typically do is use make only for what it is good: as a dependency resolution back-end. All the build logic for my projects is written in Python, in an executable file stored in the project root directory and called "make" (I have "." in my PATH). The Python script, when it runs, generates on the fly a clean, lean, readable, unrolled, Makefile and feeds it directly to /usr/bin/make via a pipe. Works like a charm: Python (a sane and expressive programing language) to express the high-level logic needed to build the project. Make as a solid back-end to solve the "what needs to be rebuilt" problem (especially the parallel version with -jXX)

m_mueller 7y ago
There's at least one more usecase IMO: definition of common development lifecycle steps in a shared Makefile across services. At my current workplace, instead of having a bunch of bash scripts in every service, I just give every service repo a Makefile that usually is a oneliner where common.mk is included. this just wraps docker-compose and gives us commands like make, make run, make stop, make lint, make test, make help etc. This way we can e.g. have repos using completely different technology stacks but the interface to them is the same - whether it's our database, a node.js webservice, a python data analytics tool etc. and the definition of these lifecycle commands in common.mk are totally trivial, they're just .phony. one-liner rules.
- williamdclt 7y ago
  That works, but isn't particularly a Make feature. That'd be just as easy to do in bash, python, ruby, JS...
  - TOGoS 7y ago
    Yes, but a Makefile is a sensible place for documentation on how to build and run everything (that happens to be executable). If there's a bunch of scripts all over, I'm not going to know which one I'm supposed to run. And it's probably not going to resolve dependencies for me.
zem 7y ago
i like make primarily as an 'entry point'. there are better tools for dependency management and building, usually language-specific, but as the OP notes, that also requires remembering each tool's invocation details, and documenting them in the README for anyone else wanting to build your project. it's easier to capture the tool invocation in a Makefile and let that serve as your primary interface.
iandinwoodie 7y ago
Could you provide an example of this (or point me to a repo where you use it)? It sounds neat
acqq 7y ago
> Make as a solid back-end to solve the "what needs to be rebuilt" problem (especially the parallel version with -jXX) I consider it a poor back-end for parallel execution, as it doesn't serialize the outputs. I personally like ninja build tool as a very "low level" parallel "making" engine. https://ninja-build.org/ https://ninja-build.org/ "Command output is always buffered. This means commands running in parallel don’t interleave their output, and when a command fails we can print its failure output next to the full command line that produced the failure. "
- deleted 7y ago
  [deleted]
d0mine 7y ago
pyinvoke can be used to define Makefile-like tasks in Python. http://www.pyinvoke.org/ http://www.pyinvoke.org/ http://fabfile.org http://fabfile.org allows to execute the commands remotely via ssh
- ur-whale 7y ago
  Do either of these solve dependencies and partially executed dependency graph rebuild like make does?
  - d0mine 7y ago
    It is not about specific building scheme for dependencies that make uses. It is more about "all-purpose" stuff: automate tasks that you run manually or via CI in a general purpose language.
de_watcher 7y ago
This kind of projects always makes me sad: you've got to read and debug through an impenetrable wall of custom python code to understand why the build fails.
- ur-whale 7y ago
  I guess you didn't read the part that says it generates a simple unrolled Makefile. That's way more debuggable than the crap that ie configure generates.
  - de_watcher 7y ago
    I guess you didn't read my comment at all. When it fails it doesn't. And if you need to bring up Autotools that weren't brought up by anyone in this thread then that justification isn't sound at all.

m_mueller 7y ago

There's at least one more usecase IMO: definition of common development lifecycle steps in a shared Makefile across services. At my current workplace, instead of having a bunch of bash scripts in every service, I just give every service repo a Makefile that usually is a oneliner where common.mk is included. this just wraps docker-compose and gives us commands like make, make run, make stop, make lint, make test, make help etc. This way we can e.g. have repos using completely different technology stacks but the interface to them is the same - whether it's our database, a node.js webservice, a python data analytics tool etc. and the definition of these lifecycle commands in common.mk are totally trivial, they're just .phony. one-liner rules.

williamdclt 7y ago
That works, but isn't particularly a Make feature. That'd be just as easy to do in bash, python, ruby, JS...
- TOGoS 7y ago
  Yes, but a Makefile is a sensible place for documentation on how to build and run everything (that happens to be executable). If there's a bunch of scripts all over, I'm not going to know which one I'm supposed to run. And it's probably not going to resolve dependencies for me.

zem 7y ago

i like make primarily as an 'entry point'. there are better tools for dependency management and building, usually language-specific, but as the OP notes, that also requires remembering each tool's invocation details, and documenting them in the README for anyone else wanting to build your project. it's easier to capture the tool invocation in a Makefile and let that serve as your primary interface.

iandinwoodie 7y ago

Could you provide an example of this (or point me to a repo where you use it)? It sounds neat

acqq 7y ago

> Make as a solid back-end to solve the "what needs to be rebuilt" problem (especially the parallel version with -jXX) I consider it a poor back-end for parallel execution, as it doesn't serialize the outputs. I personally like ninja build tool as a very "low level" parallel "making" engine. https://ninja-build.org/ https://ninja-build.org/ "Command output is always buffered. This means commands running in parallel don’t interleave their output, and when a command fails we can print its failure output next to the full command line that produced the failure. "

deleted 7y ago
[deleted]

d0mine 7y ago

pyinvoke can be used to define Makefile-like tasks in Python. http://www.pyinvoke.org/ http://www.pyinvoke.org/ http://fabfile.org http://fabfile.org allows to execute the commands remotely via ssh

ur-whale 7y ago
Do either of these solve dependencies and partially executed dependency graph rebuild like make does?
- d0mine 7y ago
  It is not about specific building scheme for dependencies that make uses. It is more about "all-purpose" stuff: automate tasks that you run manually or via CI in a general purpose language.

de_watcher 7y ago

This kind of projects always makes me sad: you've got to read and debug through an impenetrable wall of custom python code to understand why the build fails.

ur-whale 7y ago
I guess you didn't read the part that says it generates a simple unrolled Makefile. That's way more debuggable than the crap that ie configure generates.
- de_watcher 7y ago
  I guess you didn't read my comment at all. When it fails it doesn't. And if you need to bring up Autotools that weren't brought up by anyone in this thread then that justification isn't sound at all.