diff options
Diffstat (limited to 'mds/lazymakefiles.md')
| -rw-r--r-- | mds/lazymakefiles.md | 98 |
1 files changed, 98 insertions, 0 deletions
diff --git a/mds/lazymakefiles.md b/mds/lazymakefiles.md new file mode 100644 index 0000000..fab72e3 --- /dev/null +++ b/mds/lazymakefiles.md @@ -0,0 +1,98 @@ +[original Medium post](https://medium.com/@thabogre/lazy-makefiles-ce1997412700) + +# 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.<br/> +Yes, I'm lazy.<br/> +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?<br/> +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.<br/> + +First off, you can find the makefiles [here](https://github.com/bloodstalker/lazymakefiles). They are licensed under the Unlicense. And I'm using plural because there's one for C and one for C++.<br/> +Now that we are done with the mandatory whimsical introduction, let's talk about the contents of the makefiles.<br/> +There are also a couple of things to note:<br/> +* 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.<br/> +* 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.<br/> +* The makefile recognizes the following extensions: `.c` and `.cpp`. If you use different extensions, change the makefile accordingly.<br/> + +## 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.<br/> +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:<br/> +```make +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.<br/> +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.<br/> + +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.<br/> + +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`.<br/> + +## Targets + +### default +The default target is `all`. `all` depends on `TARGET`.<br/> + +### 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).<br/> + +### 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.<br/> +The file's contents look like this:<br/> +```make +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 `cd`ing into a folder will generate the `.depend` file for me.Lazy and Convinient.<br/> + +### 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.<br/> + +### TARGET +Vanilla i.e. the dynamically-linked executable.<br/> + +### TARGET-static +The statically-linked executable.<br/> + +### TARGET-dbg +The dynamically-linked executble in debug mode.<br/> + +### TARGET-cov +The instrumented-for-coverage executable, dynaimclly-linked.<br/> + +### 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.<br/> + +### covrep +The exact same as above but generates coverage report in a different format.<br/> + +### ASM +Generates the assembly files for your objects, in intel style.<br/> + +### SO +Will try to build your target as a shared object.<br/> + +### A +Will try to build your target as an archive, i.e. static library.<br/> + +### 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.<br/> + +### 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.<br/> + +### 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.<br/> + +### 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.<br/> + +### help +prints out the condensed version of what I've been trying to put into words.<br/> + +Well that's about it.<br/> |