Lazy makefiles for C and C++.
It's the Unlicense so feel free to do whatever you want with the makefiles.
Add a generic makefile for building clang stand-alone plugins(clang tools).
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.
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.
- The makefile recognizes the following extensions:
.cand.cpp. If you use different extensions, change the makefile accordingly.
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?=clangIt 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.
The default target is all. all depends on TARGET.
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 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.hThe 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.
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.
Vanilla i.e. the dynamically-linked executable.
The statically-linked executable.
The dynamically-linked executble in debug mode.
The instrumented-for-coverage executable, dynaimclly-linked.
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.
The exact same as above but generates coverage report in a different format.
Generates the assembly files for your objects, in intel style.
Will try to build your target as a shared object.
Will try to build your target as an archive, i.e. static library.
Depends on the tags target, generates a tags file. The tags file includes tags from the header files included by your source as well.
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.
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 cleans almost everything. deepclean depends on clean. basically a two level scheme so you can have two different sets of clean commands.
prints out the condensed version of what I've been trying to put into words.
Well that's about it.