Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>After reading the RMCH paper, I set out with the goal of writing a proper non-recursive Makefile for a small project I was working on at the time. After I finished, I realized that it should be possible to create a generic Makefile "framework" which can be used to very simply and concisely tell make what final targets you would like to build, what kind of targets they are (e.g. libraries or executables) and what source files should be compiled to make them.</p> <p>After a few iterations I eventually created just that: a single boilerplate Makefile of about 150 lines of GNU Make syntax that never needs any modification -- it just works for any kind of project I care to use it on, and is flexible enough to build multiple targets of varying types with enough granularity to specify exact compile flags for each source file (if I want) and precise linker flags for each executable. For each project, all I need to do is supply it with small, separate Makefiles that contain bits similar to this:</p> <pre><code>TARGET := foo TGT_LDLIBS := -lbar SOURCES := foo.c baz.cpp SRC_CFLAGS := -std=c99 SRC_CXXFLAGS := -fstrict-aliasing SRC_INCDIRS := inc /usr/local/include/bar </code></pre> <p>A project Makefile such as the above would do exactly what you'd expect: build an executable named "foo", compiling foo.c (with CFLAGS=-std=c99) and baz.cpp (with CXXFLAGS=-fstrict-aliasing) and adding "./inc" and "/usr/local/include/bar" to the <code>#include</code> search path, with final linking including the "libbar" library. It would also notice that there is a C++ source file and know to use the C++ linker instead of the C linker. The framework allows me to specify a lot more than what is shown here in this simple example.</p> <p>The boilerplate Makefile does all the rule building and automatic dependency generation required to build the specified targets. All build-generated files are placed in a separate output directory hierarchy, so they're not intermingled with source files (and this is done without use of VPATH so there's no problem with having multiple source files that have the same name).</p> <p>I've now (re)used this same Makefile on at least two dozen different projects that I've worked on. Some of the things I like best about this system (aside from how easy it is to create a <em>proper</em> Makefile for any new project) are:</p> <ul> <li>It's <em>fast</em>. It can virtually instantly tell if anything is out-of-date.</li> <li>100% reliable dependencies. There is zero chance that parallel builds will mysteriously break, and it always builds <em>exactly</em> the minimum required to bring everything back up-to-date.</li> <li>I will <em>never</em> need to rewrite a complete makefile again :D</li> </ul> <p>Finally I'd just mention that, with the problems inherent in recursive make, I don't think it would have been possible for me to pull this off. I'd probably have been doomed to rewriting flawed makefiles over and over again, trying in vain to create one that actually worked properly.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload