Skip to content

Instantly share code, notes, and snippets.

@terminaldweller
Created April 1, 2019 11:51
Show Gist options
  • Save terminaldweller/fd2763f7d03d37b79f20a3c0b033bb37 to your computer and use it in GitHub Desktop.
Save terminaldweller/fd2763f7d03d37b79f20a3c0b033bb37 to your computer and use it in GitHub Desktop.
Lazy Makefiles

Lazy Makefiles

I kept finding myself needing to build some C or C++ code but I just couldn't be bothered to write a makefile from ground up. My life's too short for that. The code was either not that big of a deal or the build process was not anything complicated.
Yes, I'm lazy.
The alternative to writing a makefile is just typing in gcc or clang instead of make into the terminal. I know. The horror. It's 2018. What sort of a barbarian does that?
So I just decided to write a lazy makefile so I would never have to type in the name of my compiler of choice ever again. Mostly because that's what you do with things that you love. Forget about them until you need them. We're still talking about compilers and makefiles for your information. Don't go assuming things about my personal life.

First off, you can find the makefiles here. They are licensed under the Unlicense. And I'm using plural because there's one for C and one for C++.
Now that we are done with the mandatory whimsical introduction, let's talk about the contents of the makefiles.
There are also a couple of things to note:

  • The makefiles have been written with gnu make in mind.
  • Most targets will be fine with gcc but the full functionality is achieved by using clang.
  • This is not a makefile 101.
  • I'm not going to try to copy the makefile contents here line by line. You are expected to have the makefile open while reading this.
  • I will be explaining some of the more, let's say, esoteric behaviours of make which can get the beginners confused.
  • gnu make variables are considered macros by C/C++ standards. I will use the term "variable" since it's what the gnu make documents use.
  • The makefiles are not supposed to be hands-off. I change bits here and there from project to project.
  • The makefile recognizes the following extensions: .c and .cpp. If you use different extensions, change the makefile accordingly.

The Macros

TARGET holds the target name. It uses the ?= assignment operator so you can pass it a different value from a script, just in case.
There are a bunch of varibales that you can assign on the terminal to replace the makefile's defaults. Among those there are some that are first getting a default value assigned and then get the ?= assignemnt operator so you can assign them values from the terminal, e.g:

CC=clang
CC?=clang

It looks a bit backwards but there is a reason for that. The reason why we need to do that is because those variables are called implicit variables in gnu make terminology. Implicit variables are already defined by your makefile even if you havent defined them so they get some special treatment.
In order to assign them values from the terminal, we first assign them a value and then use the ?= operator on them. We don't really need to assign the default value here again, but I felt like it would be more expressive to assign the default for a second time.

Variables CC_FLAGS, CXX_FLAGS and LD_FLAGS have accompanying variables, namely CC_FLAGS_EXTRA, CXX_FLAGS_EXTRA and LD_FLAGS_EXTRA. The extra ones use the ?= assignment. The scheme is to have the first set to host the invariant options and use the second set, to change the options that would need changing between different builds, if need be.

The variable BUILD_MODE is used for the sanitizer builds of clang. ADDSAN will build the code with the address sanitizer. MEMSAN will build the code with memory sanitizer and UBSAN will build the code with undefined behaviour sanitizers. The build mode will affect all the other targets, meaning you will get a dynamically-linked executable in debug mode with address sanitizers if you assign MEMSAN to BUILD_MODE.

Targets

default

The default target is all. all depends on TARGET.

all

all is an aggregate target. calling it will build, or rather, try to build everything(given your source-code's sitation, some targets might not make any sense).

depend

depend depends on .depend which is a file generated by the makefile that holds the header dependencies. This is how we are making the makefile sensitive to header changes.
The file's contents look like this:

main.c:main.h
myfile1.c:myfile1.h myfile2.h

The inclusion directive is prefixed with a -. That's make lingo for ignore-if-error. My shell prompt has a make -q part in it so just cding into a folder will generate the .depend file for me.Lazy and Convinient.

Objects

For the objects, there are three sets. You have the normal garden variety objects that end in .o. You get the debug enabled objects that end in .odbg and you get the instrumented objectes that are to be used for coverage that end in .ocov. I made the choice of having three distinct sets of objects since I personally sometimes struggle to remember whether the current objects are normal, debug or coverage. This way, I don't need to. That's the makefile's problem now.

TARGET

Vanilla i.e. the dynamically-linked executable.

TARGET-static

The statically-linked executable.

TARGET-dbg

The dynamically-linked executble in debug mode.

TARGET-cov

The instrumented-for-coverage executable, dynaimclly-linked.

cov

The target generates the coverage report. it depend on runcov which itself, in turn, depends on $(TARGET)-cov so if you change runcov to how your executable should run, cov will handle rebuilding the objects and then running and generating the coverage report.

covrep

The exact same as above but generates coverage report in a different format.

ASM

Generates the assembly files for your objects, in intel style.

SO

Will try to build your target as a shared object.

A

Will try to build your target as an archive, i.e. static library.

TAGS

Depends on the tags target, generates a tags file. The tags file includes tags from the header files included by your source as well.

valgrind

Depends on $(TARGET) by default, runs valgrind with --leak-check=yes. You probably need to change this for the makefile to run your executable correctly.

format

Runs clang-format on all your source files and header files and EDITS THEM IN PLACE. Expects a clang format file to be present in the directory.

clean and deepclean

clean cleans almost everything. deepclean depends on clean. basically a two level scheme so you can have two different sets of clean commands.

help

prints out the condensed version of what I've been trying to put into words.

Well that's about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment