"Makefiles are machine-readable documentation ... "
Yes it is machine readable but how about us humans? Makefiles are ugly and when working on someone else's project it is very hard to reverse engineer the build system. Build systems are themselves software projects and we need better tools to develop and maintain them.
SCons was a promising project at one point, it improved things by capturing the build system in Python classes. I thought things would be more maintainable and readable. However for me it wasn't a well design, it obscures build system development with mixed declarative and iterative programming.
Makefiles are the defacto standard today, but they're no where near beautiful, or maintainable, or readable.
There are also variations of it such as gmake, imake, and so on, who only add their own quirks without solving the real problems.
I know some folks like it in all it's python-y glory, but I found it opaque and horrible. Finding where things are done and how to change its behaviour was surprisingly hard work. Now this may have been at least partly due to the way the project was set up but... well just give me a nice Makefile any day.
First: Python, as a general purpose language, looks terrible in build rules
compared to dedicated build tools. Yes, this includes makefile. You probably
have just never seen a well-written makefile (programmers rarely think of it
as a code, even though `make' is a programming language).
Yep, sure. I _personally_ don't like makefiles because it's another language that's need huge amount of code (relatively to the rest of the code). That's pretty annoying
And about scons: probably heard someday, i don't sure. Anyway it's look quite big
I've uses my fair share of build tools and I think makefiles are horrible. Stringly typed, ad-hoc features, and a really bad language from a PL perspective.
Writing good build systems is genuinely hard, and I think make is not a good build system.
I dunno, I've never seen a readable Makefile in any system above say 300 files. If you could write readable declarative Makefiles getting the job done, would there be autotools? This is not to say that autotools get the job done beautifully, just that their existence demonstrates how the problem gets us all contort violently to terrible effect like a wounded animal screaming and running into trees.
I admit that I despise make and maybe I don't get the beauty (I get the beauty of the idea but I've never seen it result in actual beautiful Makefiles), and maybe if you linked to what you consider a good open source Makefile, we could discuss this in more concrete terms.
That didn't come out right - I meant that sometimes people get the impression that make is incredibly complex because they look at makefiles generated by the autotools. Those makefiles are typically very different from hand-written ones.
I personally reach for Makefiles in exactly one situation: in research, when I’d like to collect lots of results from many computational experiments to make some plots or tables. I might have the whole process of re-running the experiments and rebuilding the final manuscript driven by Make. But even for this task, it feels pretty awkward and painful. I did try using Scons for the same purpose but didn’t like it as much.
SCons is fine for working with builtin rules. It's kind of a mess for writing elaborate custom rules, for the same reason that python is a poor command line tool integration language when compared with the shell (of which make is, essentially, a superset). The same is true for cmake, or the GNU autotools, or ant, etc...
I happen to like make. It's true that as a programming language it's pretty weak. And it doesn't do anything for the "C portability" problems that the other tools try (with varying degrees of success) to solve. But as a way to wrap a bunch of short shell scripts together with some dependency management in an easy to maintain way, it's better than anything else I've seen.
> There is a huge population of us that smile and get things done, while others screw around with new, complicated, never-learned-the-past tools.
They get the things done they've been doing all along. But build metadata is very important and very hard to extract from Makefiles, especially as builds increase in complexity.
You need things like search paths accessible to get IDEs, static analyzers, software packaging systems, and other third party tools working with your code base.
So make works great if the only things you're interested in doing are the top-level make commands you define, but it doesn't do you any favors when it comes to other things.
Depends what you're using it for. Generated from CMake, Makefiles are OK I guess, although Ninja is strictly better these days.
Manually written, I would say make is bad.
1. It doesn't promote portability: since each target calls shell commands, it is very easy to accidentally create a non portable Makefile (something alleviated when using CMake that handles the portability before emitting the Makefile)
2. It is imperative and stateful in subtle ways, which is the wrong level of abstraction for a build system. Systems that are declarative and describe the desired state of the build are much easier to use and reliable
3. It is bare bone as far as build system functionality goes: it doesn't provide many of the useful things I expect from a modern build system: the concepts of library dependencies, build profiles, compiler flags, test, documentation or even project in general... are all orthogonal to make
4. It is ad-hoc: as a result of the previous points, the expected functionality of a build system is often re-created in the makefile, but in a non fully standard way (conventions exist, but must be manually enforced and are limited). This results in brittle and difficult to use build systems.
If using rust, there's also a pattern called xtask[1] that's aiming at providing a standard interface in the form of a binary (since it is rust, it is portable, but most of the other points unfortunately apply).
Scons and CMake are both heavier garbage, for mostly the same reasons: both require unnecesary dependencies, Scons requires Python which is a monster, and CMake is a bitch to build. Neither fully implement all of Make's capabilities, because both authors never really mastered Make and misunderstand it.
As a final slap to CMake, in the end it generates Makefiles, proving that Make is the be all, end all when it comes to build engines.
You better buy the book on Make and learn it and learn it well instead of wasting your time on toy tools. The longer you try to avoid it, the more time you'll waste.
They had tons of makefiles, so moving to something make-like was desirable.
I personally think that GNU make has a ton of bells and whistles, so it may be very difficult to emulate it with any accuracy; then again, they also know which features of GNU make are important to their project.
I might have bitten the bullet and chosen something like SCons to reach a Python base, and I have spent time rewriting (one or two) makefiles as SConstructs without a problem. But I have also seen huge projects with makefile madness, and I can certainly understand anyone's decision to want to keep makefiles untouched. Emulating make, while leaving room for improvements, isn't such a bad decision.
I think people write bad makefiles because the documentation is bad. Its "taking the user by the hand and pushing him into the right direction"-level is just not up to date anymore.
Make is a good tool because it allows a lot of flexibility, but it doesn't protect its users from the pitfalls this flexibility unavoidably creates.
Yes it is machine readable but how about us humans? Makefiles are ugly and when working on someone else's project it is very hard to reverse engineer the build system. Build systems are themselves software projects and we need better tools to develop and maintain them.
SCons was a promising project at one point, it improved things by capturing the build system in Python classes. I thought things would be more maintainable and readable. However for me it wasn't a well design, it obscures build system development with mixed declarative and iterative programming.
Makefiles are the defacto standard today, but they're no where near beautiful, or maintainable, or readable.
There are also variations of it such as gmake, imake, and so on, who only add their own quirks without solving the real problems.
reply