I do like simple makefiles. I adopted a C++-project without having much C++-knowledge, and simplifying the build setup was a big step in making it mine.
Which raises kind of an important point: Simple means understanding what is happening. I have no idea why `$(CC) $(OBJS) -o $@ $(LDFLAGS)` does raise that error - and just like that it is not simple for me anymore.
Edit: Now with the tab-error out of the way, it of course does not find the dependencies. That might be caused by a strange project organization (like said, it is an adopted project) or maybe the makefile is just not complete – I'm not sure how far the auto-generation is supposed to go. Played a bit with it, but that just removes the simplicity. For now, I think that the pkg-config way is nice and explicit, and would recommend to take a look at the linked makefile if a simple one is searched. Though I still would be happy about optimizations for that file!
I of course just might miss the point. Well, after all that supports mine: Not that simple after all.
The tabs in the makefile have been converted to spaces by the blog-posting software.
The commands for implementing rules are always indented by a tab. This is a classic makefile newbie make gotcha & everyone gets bitten by it at some point or other.
If you cut & paste the makefile in the blogpost, you’ll discover that the blog itself has converted the tabs in the makefile to spaces. Not very helpful to any confused newbies out there!
I strongly disagree. The tab requirement for Make is very well known and less strange than custom Makefile generation. Simple Makefiles work extremely well in lots of projects.
Somebody listed a number of common build system requirements below, but of course there are usually many many more like custom compilers, cross-compilation, any number of things that your "simple makefile" can't work with.
By the time the Makefile has grown to support all these things it no longer has the properties that made it useful in the first place (parsimonious, understandable, small).
Perhaps, but I suspect writing a portable Makefile is not as difficult as you think.
Speaking as a packager, I have to patch many CMake build systems for portability issues. And don’t even get me started on SCons. Autotools is better in that regard, but has many flaws of its own.
I mean, if you're going to be generating it anyways, just generate ninja files. They are faster, but the downside is just that you need to generate them, as opposed to being generic.
It always annoys me that we don't have better solutions for building C and C++ projects by now. My own take on the generic drop-in makefile[1] has over 1000 stars on github, which says pretty loudly to me that this is a common pain point for many people. Alas I haven't had a brilliant idea for a solution (yet).
- proper module system, none of this header file nonsense
- no compiler flags to worry about
- no preprocessor definitions to worry about
- as a consequence of the above, no dependencies that require their own linker flags, include directories and preprocessor definitions to work
- no need to support different compilers/platforms with different configurations (which work differently with libraries that require different linker flags and include directories and...)
Out of curiosity, how do other languages cope with:
a. Targeting different release types (debug vs release)
b. Changing behaviour of the compiler
c. Having different code paths between debug and release (#ifdef _DEBUG)
d. Having macros and helpful macro expansion
I do not understand the dislike of header files: how would you recommend distributing DLLs and libs while exposing their functions to be developed against?
I suppose you could implement everything in a header file if you wanted a simple "module" system (thinking of the header as a module), but this would establish a very simple system with no interdependencies or reusability.
> I do not understand the dislike of header files: how would you recommend distributing DLLs and libs while exposing their functions to be developed against?
Do you enjoy writing out all your function signatures twice? Haven't you ever wished the compiler could automatically build the header file for you?
d. no macros and most people seem to agree that's a good thing; C macros are not really the kind of tool you want to be using, unless forced to; code generation is used instead
Regarding header files: Javadoc for humans, code inspection on the class files for IDEs. No need for separate files in a system designed after the 70s :)
We do. We have decent tooling (Visual Studio, Xcode) which let us set options and let us run compilers from the commandline using the options in the project and solution files (nmake, msbuild, xcodebuild) to save us having to use a hand-written Makefile.
If you're still writing small projects and insisting on running a build in a command window, or writing code in a simple editor then I can perhaps understand the complaint. But you quickly grow out of that when you start writing larger projects.
I couldn't imagine the 2+ million line codebase at work using hand-written makefiles. It builds for debug, release, MBCS and Unicode, and with different versions from source control every night, so multiple versions for different branches are built.
Usually if you're distributing a Makefile with a project, it's for portability. Insisting that your Linux users of a C/C++ library install Visual Studio or Xcode is a complete non-starter. It's different at a company - every company I've been at had its own proprietary wrapper around make - but then you need to be able to integrate all the open source libs you're depending on.
At least there's autotools, which has its own set of problems, but you can be reasonably confident it'll generate a portable Makefile.
Pretty much all of this can be done trivially in a makefile, using a very innovative construct called "variables".
> parallel builds
make -j. Works especially well if you have working dependencies. This makefile does.
> conditional features
make has ifdef... Granted this makefile uses find to discover source files, which won't totally work. But it's a small fix. Or you can do conditional features through CFLAGS.
Can be done. The question is will the half-assed Makefile that a developer wrote for themselves do any of those things? And I can tell you from bitter experience that is very very unlikely. Plus I will still have to spend the time to understand the Makefile, which I won't need to do if they'd used an established build system in the first place.
We can agree that half assed makefiles are bad. I don't believe in throwing out the tool on that basis. If that were the bar, we might as well not write any software in any language with any tool.
I imagine most projects will never leave the hard drive they're first written to. Writing a basic "half-assed" makefile that works for the initial author is fine. If a project turns out useful, rewrite the makefile as people need the compatibility. There's little point in wasting the time when you're just starting out.
Autotools does do all of those things. I'm not a particular fan of it either, but when I'm packaging software for a Linux distro then I'd rather see autotools or cmake being used instead of some crappy custom build system that will require patching to make it work.
There is room for someone to come up with a good build system. It had better do everything autotools and cmake do, and be well documented and widely used, so there's a rather large barrier to entry.
Whenever "configure" is looking for a fortran compiler in a clearly non-fortran program, one has to wonder why no one fixes the configure scripts. From all I learned it is, because the underlying scripts are close to unmaintainable. So from that perspective, a better build tooling should be a high priority.
No one fixes the configure scripts because they're thousands of lines of code in about three different archaic languages that nobody knows or cares about.
autotools is pretty great for the end-user who wants to compile your code or the distributor who wants to package it up for Debian or whatever.
It’s a crawling horror for the programmer that wants to use autotools as the build solution for their code however, which is the topic under discussion.
This only works in the Unix world, on Mac only for command line tools (but only after installing autoconf and make), and not at all on Windows unless you install a complete Unix environment (cygwin or mingw).
Not really. the end user doesn't need autotools installed actually. To build the configure script from the "configure.in" file, you need autotools. Go ahead and try!
It's not that hard. I recently had to debug a memcached configure.in script. But, I consider myself a C programmer, so that fact might be source of bias.
>And no, “just use autotools” is not a viable answer.
After packaging hundreds of programs for a GNU/Linux distro and dealing with handwritten Makefiles and other so-called autotools replacements: Yes, it is.
If you want someone to be able to build and install your software, just use the Autotools. Yup, they are ugly, but they're still the only set of tools that works acceptably.
Not only that, but every time I'm up against a problem building software that uses something else, it's like, "oh great now I have to figure out what their secret badly-documented variable names are and how to configure their XML/JSON/YAML/whatever"
It's a pleasure when autotools is used because in generally I know it's going to be nothing much more than
> --with-stuff/--without-stuff
and
> --prefix=$HOME/.local
and when it's not, at least I know I can just grep the shell script and figure it out pretty quickly without having to learn a whole new programming language.
It does all those things. It's fast. It's cross-platform. The language is Python.
It's a bit steep to learn and maybe doesn't have the most mature built-in recipes for certain complex builds like mobile or desktop frameworks, but it seems like those things would be addressed quickly if more people were using it. The maintainer is a class act, consistently putting out new features and bug fixes and working with pull requests.
WAF is not so much a build system, but a bunch of python scripts to create your own build system, it's in the same zoo as cmake, scons or premake, but (in my opion) worse than any of those. I might have had a bad first impression though because of the project I had to use WAF in had terribly complex WAF scripts.
True, they do call it a build system toolkit. But I think worse than the others is on the wrong track and the sentiment is too heavily influenced by your negative first impression.
swtoolkit made scons really nice to work with (but couldn't fix the speed issues). It's a shame it was abandoned. In the same way, a thin layer of functions as demonstrated in the waf "toolkit" examples could lean on the power of waf and provide a build system every bit as snazzy as big, polished systems like bazel and buck, but it would work cross-platform out of the box and be extensible with only Python. But I think waf is close enough to being high level that no one bothers to create and polish a build system layer (maybe internally in companies, but the open source uses I've seen use pretty standard waf scripts).
The LibreOffice build system (which is plain GNU Make, without generated unreadable intermediate build files) does all these and more. Doing the same with autotools would be a nightmare.
... as we would have needed for CMake or Autotools. It might have worked with the former for something as complex as LibreOffice, but GNU make being so simple/basic and stable over the years was a big plus: Im sure even with CMake LibreOffice would have had fun with lots of small cornercase regressions.
Just use cmake or scons. In 2016, you should not hand write a single makefile !
A simple cmake/sconcs build file will be as simple as the one shown (or even simpler !) and it will definitively will be easier to integrate external dependencies if you have to.
Please do not use scons in your projects. Poorly written SConstructs are as common as poorly written Makefiles, and are more difficult to patch to work correctly because of all the magic that goes on under the hood.
As an OpenBSD packager, I hit many of those issues and a few more. For example, scons’s C preprocessor support is not great, and often brings in header dependencies that should be #ifdef'd out; when those unnecessary headers are removed during build (happens often on a machine bulk building packages), the build breaks.
I’ve replaced SConstructs with Makefiles before. Typically it makes the build faster, simpler, and more portable, and is popular with other OS packagers. Example: https://github.com/sinamas/gambatte/pull/6
Honestly cmake is such a shitty language though. Scons is slow.
CMake is almost great, but I have no idea why they went ahead and designed the _language_ the way they did. (Lists are concatenated strings, everything is basically macro expanded, etc..) I mean, if they were trying to improve on m4 and shell script, I wouldn't exactly say they succeeded.
I realize that CMake has better cross-platform support, but I can't stand using it. For small projects it's fine, but for medium- to large-sized projects it's a bigger headache than autotools imho.
(That said, I explicitly don't care about Windows support, which is the only place where it really matters to have something different than autotools, and even that is not so bad with MingW and will be even better, it seems, with the coming "linux-compatible subsystem")
cmake generally works great, but the larger and more complex the project gets (and the more platforms you need to support), it gets exponentially uglier. I've had the displeasure of needing to maintain a single cmake infrastructure for a large (~500K or so lines plus 3rd party libs) project that targeted Windows, Linux, Mac, iOS, Android, and a few other obscure mobile platforms. Here was the progression:
1. Linux target: "Wow this is a breeze!"
2. Mac target: "Ahh, a little learning curve, but no problem!"
3. Windows/VC target: "Jeez, I hope I don't have to hand-edit this monstrous vcproj this thing generates..."
4. iOS: "WTF!! Simulator targets, device targets, provisioning profiles, code signing.. This stuff was all just hacked into cmake and barely made to work wasn't it??"
5. Android+NDK: "Kill me now"
6. Other obscure mobile targets with toolchains themselves that barely worked: "La La La, I'm ready for the funny farm. The cucumbers! They're dancing! And glowing!! The room is getting hazy and dark.. Where's my vodka?"
Honestly, I don't think I could afford the therapy that I would need to re-live that part of my career in the detail that it would take to do a proper write-up. To this day, I still have no idea how an Android project actually winds up getting built, and their build system philosophy seems to boil down to "keep adding layers of magic, each making lower levels of magic harder to hand-edit and understand".
Most of the difficulty to be honest was with: 1. third party libraries, and 2 the Android NDK.
For third party libraries, every one was slightly different in some frustrating way. Some of them used bog-standard makefiles (thank you, third party developers who do this!), so they basically just worked. Some of them used autoconf/automake, which makes me sad but you can generally get cmake to mate successfully with them. Some of them helpfully had their own CMakeLists.txt, which would build the library, but invariably could never be successfully integrated into a larger project. Some non-open-source libraries came with just one platform's build support, so you'd have to hand-build CMake support for them, and guess which files actually needed to be built/linked. Some of them cleverly generated some of their own source files during the build process ("This is fun to maintain" said nobody ever).
The Android NDK seems to be some Googler's frankenstein hobby project that got accidentally electrified into life and set loose on the world. Like Donald Trump, the NDK is kind of an embarrassing offshoot from the "mainstream Android development story," one that Google would like to pretend doesn't exists. They, in fact, tell you in their docs "Yea, you can use native C and C++ to write Android apps with this thing, but you really shouldn't!" [1] Seriously, their "Getting Started" guide spends a paragraph or so trying to convince you not to get started. Convincing Google's own development tools to build C++/NDK is pretty frustrating itself, so you can imagine how difficult it is to convince cmake to do it.
In short, if you are working on a project that targets desktop, embedded, and mobile platforms and has lots of third party code, and one day that little voice in your head starts saying "Hey we waste a lot of time maintaining separate Makefile, .xcodeproj, .vcproj, etc. Why don't we switch to a single glorious build system that lets us list our source files in one place!?" IGNORE THAT VOICE. Go play some foosball, fix a few bugs, have a cup of coffee, but by no means try to use cmake for this.
I've had a similar experience getting shit to work on multiple platforms. I decided not to use cmake for mobile targets. While the NDK in general sucks to build, if you follow certain patterns you can get a system that works and is fairly straightforward. The path to get there is not easy though, I'll give you that.
I use CMake for everything-that-isn't-$work-now because that's the only thing CLion supports. Even at work I've taken to creating my own CMakeLists.txt so I can get CLion support. I like the IDE that much.
It's not perfect, as others have touched on. But it overall satisfies my requirements and I can usually get things done with it.
Being a Google employee, I'm somewhat partial to Bazel (https://bazel.io/) which is based on what we use internally. I've started to ponder what it would take to write a CMakeLists.txt generator for it.
Prr cmake and scons are dog slow. Make isn't exactly fast either. I didn't realise how slow they were until I used QBS which is so fast you sometimes think it hasn't done anything.
Exactly. When evaluating a language / build system / whatever, it is definitely not sufficient to look at Hello World. You have to evaluate the worst case and average case if you want to get an idea of what you're in for. Looking at the "best case" (simple one-file project) tells you almost nothing except how hard it is to get started.
When evaluating build systems, one of my major questions is: How much "magic" will I have to work-around in order to do something off the beaten path that the build system's developers never considered?
The thing is that these are not equivalent hello worlds. I mean, if only for the fact that the cmake example does proper header dependency management, which is essential to correctly compiling c/c++ code as it changes. It's not something you can leave out of a makefile and still call it correct.
The problems start once you want configure stages, build directories, portability and install targets, as all of those aspects are extremely lackluster and incomplete in `scons` and you have to reinvent large parts of the build system yourself essentially for anything even mildly complex.
`cmake` is much better. The language itself is ugly and takes some getting used to, so it's a little more complicated to get started with then `scons`. `cmake` generating `Makefile`s instead of actually building the project itself also adds a layer of complexity. But once you understand the basics it's much easier to get a fully functioning build going, including configure stages, build directories, portability and all that, as cmake has all of that integrated and working right out of the box.
`cmake` feels like a complete build system, while `scons` feels like a good start for a build system that was abandoned at the halfway point.
I still use plain `make` for some Python projects (mostly .PHONY targets to run `pylint`, `autopep` and friends), but for everything that needs to get compiled `cmake` is much easier to use than plain `make`, as you don't need to reinvent a build system yourself, it already comes with almost everything you need.
This is a good start. Could be made a bit more minimal.
I'll throw my base Makefile into the fray [0].
It supports cross compilation, CFLAGS & LDFLAGS usage, dependency file generation, source file autodetection (add the file to right folder and it's automatically included in the build), library building (`make lib`), Continuous Integration (`make start_ci/stop_ci`), Continuous Testing (`make start_ct/stop_ct`), Continuous Deployment (`make start_cd/stop_cd`), Installation (`make install`), Uninstallation (`make uninstall`), parallel compilation (`make -j4`), there's some build machine detecting/autoconfiguration support, build artifact generation, and even some git shortcuts (`make gstat/make make gpush`).
All in about 190 lines of Makefile (including some comments, and lots of blank space lines). It does depend on GNU watch if you use any of the `start_/stop_` targets. I'm about to add self-documentation to it as well.
For more minimal, comprehensible approaches, see the work of the suckless people [1][2][3].
In a past life, the mega-but-autogenerated Makefile I helped maintain would store the executed command and only echo it if the command failed. And we logged everything to file, so you got nice output but all the info was there if we needed it. Didn't take that long to work out how to do it, once we'd decided it would be a nice thing to have.
I did the hiding for a while until I noticed that it slows my debugging down way too much when something breaks and I want to manually fiddle with some compiler flags. Now I let make use two separate colors: One for info I'm usually interested in and one for stuff I need to know when I need to get my hands dirty.
This approach is flawed because it uses "find" to discover the source files which means that if you delete a source file, it won't cause a rebuild since it won't see any changed files.
It's probably possible to adapt it to do that by using find much like you use gcc -MM to get header deps, generating a make snippet that you then depend the executable output on. But then we're getting pretty nasty.
The problem with Makefiles is that they don't work on Windows with Visual Studio, and generally only have very limited support in IDEs like Xcode, QtCreator, etc... and once stuff like cross-compilation and feature selection comes in, they get really messy really fast. That's where meta-build-systems like cmake etc come in. They all have their faults (cmake has a terrible scripting language), but they solve real problems for non-trivial projects.
I agree that cross-platform is tricky and in the past I have used SCons with some success for that.
Although, at least for Xcode, I can build my entire Xcode project from a Makefile: you just have to use command-line tools like "xcodebuild", and if you want a clickable version you set up a build phase that runs "make". And, while Apple’s ".xcconfig" files are not exactly "make" syntax, they support a subset that looks exactly the same so it is possible to have files with variable settings, etc. that can be referenced by both Xcode and any Makefile that needs to stay in sync. Environment variables are yet another option.
I'm going to take this opportunity to rant about sad state of C++ open source. I would reallyreally like to write some C++ but I'm not a C++ guru; so I tried installing facebook/folly and facebook/fatal on my Mac OS. That just doesn't work. It wasn't written cross platform and it probably never will. So I spun up a ubuntu VM and tried there. fatal compiles, folly still doesn't... And so ends my brief foray into C++. At that point I started researching how can I bind the library I need to Rust so I can skip all this nonsense.
C++ is not a bad language and I would like to write a project hat uses it. But I'm just a user of the language. I don't have time and expertise to tackle those build issues and quite frankly installing any library is a major PITA.
C++, regardless of open/closed source is not in a sad state IMO. The problems you describe sound like they're from the perspective of someone who's worked with much higher level languages. C++ is as good (or as bad) as it's always been, it hasn't evolved to a bad state.
New language designers have the luxury of having been bit by C/C++'s misfeatures and wrinkles. They also have the luxury of high end computers which can solve lots of problems in reasonable computation time. This means that modern languages can afford to trade off more computation resources in favor of development simplicity.
> But I'm just a user of the language. I don't have time and expertise to tackle those build issues and quite frankly installing any library is a major PITA.
I have a hard time understanding what "just a user" of the language means. It sounds like you're confessing to being a novice. That's fine, but you should be prepared to have to do a lot of work before you become proficient in C/C++. Much more so than modern languages.
Why not just use Xcode and xcodebuild from the CLI if you don't like the IDE?
I write all my OSX projects in C++ using it.
Learning to build projects and solve compiler and linker errors is part of the journey. Stroustrup's book takes longer to read than 5 minutes, so writing C++ will take longer. It is a rewarding journey, where you will suddenly find all other languages (Java, C#, C, JavaScript, Swift) very similar or simplified in comparison.
To get you started you could install xcode and the commandline tools, write your file.cpp and use:
g++ -o myprogram file.cpp
This assumes no linker options, no preprocessor options or anything, and on OSX will use clang, which it secretly symbolic links as g++. You might find it easier to get your head around it by starting a project in Xcode, setting the options in the IDE and then observing the output that it runs.
Note that installing a library on most Unix platforms isn't complicated - configure, make, make install.
BSD make (bmake) and its .mk includes are really simple, it's basically make with batteries included. Many makefiles may be reduced to two lines while no new syntax is introduced:
PROG=${.CURDIR:T}
.include <prog.mk>
It indirectly extends original BSD make. There are some syntactic differences from GNU make, but no big depart.
Nice to see people spreading good practices with Make.
Too many folks don't understand good use of Make and thus are doomed to re-invent it badly.
I've had to use too many build systems that are, basically, big and flat lists of variables you can set. And yes I'm pointing at everything from esoteric in house systems to mainstream ones. Make's system of overrides is something especially useful.
This. Make is highly underrated. It's old so it's probably clunky, has a weird syntax and dog slow. Well no. So many examples of people reinventing the wheel, it's just sad.
I do agree that VPATH is helpful, but you'd still need to put the Makefile into the build directory in that case, which is distasteful, as it's not a built file.
Also you can't really get around specifying the files or searching, unless you have one c file per executable.
Projects that make blind use of VPATH are a pain. You can't have the same filename in two different directories! It's a hack at best, and using explicit paths (as this Makefile does) is a lot more reliable.
I feel like the only person in the world that uses Boost Bjam (for a proprietary project). I feel like I should switch but every time I look into it and read comments it's not at all clear that Bjam was a bad decision - even if it feels like I was the only one to choose it :-)
It's simple, seems pretty fast but it is very hard to integrate custom build steps.
The one thing it doesn't have over this Makefile is automatic detection of source files - you need to manually specify them. I haven't found that to be prohibitive in practice.
Thinking that it might be nice, I tried this one instead of my own approach at a simple makefile (https://github.com/onli/simdock/blob/master/Makefile) and I get this error:
> Makefile:16: * missing separator. Stop.
Which raises kind of an important point: Simple means understanding what is happening. I have no idea why `$(CC) $(OBJS) -o $@ $(LDFLAGS)` does raise that error - and just like that it is not simple for me anymore.
Edit: Now with the tab-error out of the way, it of course does not find the dependencies. That might be caused by a strange project organization (like said, it is an adopted project) or maybe the makefile is just not complete – I'm not sure how far the auto-generation is supposed to go. Played a bit with it, but that just removes the simplicity. For now, I think that the pkg-config way is nice and explicit, and would recommend to take a look at the linked makefile if a simple one is searched. Though I still would be happy about optimizations for that file!
I of course just might miss the point. Well, after all that supports mine: Not that simple after all.