What about using Python (with system calls) to build the project? Much more understandable than Makefiles.
Makefiles – Best Practices
21–30 of 127 posts
Re: Makefiles – Best Practices
#22Does the "?=" operator behave like ":=" or like "=" ?
Both
$ cat Makefile
$(info FOO $(flavor FOO))
FOO ?= foo
$(info FOO $(flavor FOO))
BAR :=
$(info BAR $(flavor BAR))
BAR ?= bar
$(info BAR $(flavor BAR))
BAZ =
$(info BAZ $(flavor BAZ))
BAZ ?= baz
$(info BAZ $(flavor BAZ))
$ make
FOO undefined
FOO recursive
BAR simple
BAR simple
BAZ recursive
BAZ recursive
Re: Makefiles – Best Practices
#23I really wish blog posts like this would at least mention that they are going to use GNUMake extensions. There's some good stuff in here, but just calling it "make" and leaving it at that is misleading. It's not going to work on my minimal (non-GNU) Linux boxes that mostly run NetBSD make (bmake in many distros) or busybox style tools. I know a very small minority of people do something like that (or maybe not, what does Alpine run in containers?), but it seems worth at least a quick footnote to say that most things in here won't be portable.
Re: Makefiles – Best Practices
#24I recently decided it was time to get a better understanding of how makefiles work, and after reading a few tutorials, ended up just reading the manual. It's long, but it's very, very well written (a good example of one of the Gnu projects biggest strengths), to the point where just starting at the top and reading gives an almost tutorial-like effect. Just read the manual!
I really like the GNU Make documentation, as well.
Links to the docs in various form:
Re: Makefiles – Best Practices
#25I recently decided it was time to get a better understanding of how makefiles work, and after reading a few tutorials, ended up just reading the manual. It's long, but it's very, very well written (a good example of one of the Gnu projects biggest strengths), to the point where just starting at the top and reading gives an almost tutorial-like effect. Just read the manual!
FWIW I also read the GNU Make manual, and based some code for automatic deps off a profoundly ugly example it had. Then later people on HN showed me a better/simpler way to do it.
https://news.ycombinator.com/item?id=15060149
https://www.gnu.org/software/make/manual/html_node/Automatic...
After reading the manual and writing 3 substantial Makefiles from scratch, I still think Make is ugly and, by modern standards, not very useful.
In my mind, the biggest problem is that it offers you virtually no help in writing correct parallel and incremental builds. I care about build speed because I want my collaborators to be productive, and those two properties are how you get fast builds. GNU Make makes it easy to write a makefile that works well for a clean serial build, but has bugs once you add -j or when your repository is in some intermediate state.
Re: Makefiles – Best Practices
#26There are so many gotcha with makefiles yet we still use them regularly. I'm considering moving on to something like Taskfile [1], though I haven't tried it yet. [1]: https://taskfile.org/
I decided a long time ago that it's not worth having to install and learn a different tool for every ecosystem just to avoid make's quirks. Yes, make isn't perfect (it can even be quite annoying at times), but neither is everything else so it's worth it to me (from a personal and business perspective) to just make my developers use one thing for all projects, especially since it's already installed (or easily installable if not, there are packages for everything which may not be true of all the less popular alternatives) on most of their systems.
Not that I couldn't ever see making an exception to that, I'm sure there are some things out there that don't work with the make model and really do need their own build system, but in general make is "good enough" and it's not worth using anything else.
Re: Makefiles – Best Practices
#27What about using Python (with system calls) to build the project? Much more understandable than Makefiles.
OK, so I am as much of a hard core Pythonista as you will find. But I don't think it makes any sense to build C projects (or many other languages) with Python instead of makefiles. C programmers know make, the makefile idiom has been evolving for 40+ years. A seasoned C programmer is going to look at an idiomatic makefile and find it much more readable than some rando doing some one-off Python script to control a build. And getting build dependencies resolved correctly so that you can only build what is need is not trivial.
What I truly hate is all the IDE's that think they can do a better job than make. This is the curse of the embedded world. Building an embedded project requires calling particular tools, with peculiar flags, and I hate with a passion IDE's that obscure all of that in some crappy XML file that is git-unfriendly. A well-structured makefile is your friend in many ways.
make is a powertool. Learn it and your life will be better.
Re: Makefiles – Best Practices
#28Earlier quoted context omitted.
Make is simple.. it gets me started. I can do multiple targets with dependencies and incremental compilation.. Sure, you should be careful of scaling it far. BUT, please enlighten me on a sane high-level build system? cmake, bazel and the like all seems to rely on unintuitive macros. And let's not talk about auto tools :) What other mainstream build system will get you started quickly without unintuitive macros. (I w…
What's more simple than "add_executable(foo bar.cpp)"? It's concise, cross-platform and hides all the boilerplate for you. Sure, everything in CMake is not super intuitive, but I've led workshops were people got the hang of it pretty quickly for simple to advanced cases (including multiple targets and some scripting). Keep it simple, most of the time, you don't need the advanced features at all! Can't say the same fo…
Its here I look to KISS to guide me. A Makefile is simple and you can expect it to be on most systems, so it's a good place to start stringing things together. It helps you start building a CLI UI with relative ease, once you know you should mark all ephemeral targets as .PHONY.
As a project grows and gains users or requires more system support, the growth of Make usage to declare interdependence should always be discussed. At some point the team will need to start using a different tool, perhaps isolating Makefile usage to bootstrapping the bigger tool.
The reason I reach for Make is I know it, and it's rather intuitive for someone to glance at my Makefiles and get an overview of where to look next.
Re: Makefiles – Best Practices
#29A particularly tricky task with GNU make is automatically adding target dependencies on header files and handling updates to them (gcc's -M and -MMD switches). It would be great if the article explained those best practices, too.
https://www.cmcrossroads.com/article/tips-and-tricks-automat...
Thanks John, your book is the most-referred to on my office shelf ;)
Edit: https://nostarch.com/gnumake (via https://blog.jgc.org/2015/04/the-gnu-make-book-probably-more...)
Re: Makefiles – Best Practices
#30Next up: Automake, best practices
Publication date 2025
5000 pages