VPATH
With VPATH, you can instruct make to search for your source files in alternate directories.
This way, you can automatically handle a complicated tree of sources - let make worry about
finding your source. You only specify source filenames, not their paths (in Group0_SRC).
Which means that you must NOT use the same filename in two different VPATH directories - only the first
one will be used, if you do.

Debug and Release configurations
Just as in other developing platforms, you can define different compilation options for debug / release
builds (e.g. the CXXFLAGS in the template above) and build with...

make CFG=debug

or

make CFG=release

Your output object files will be placed in objs.debug or objs.release, and your application under
bin.debug or bin.release, respectively.

Dependencies
These will be created automatically from your C++ source code, and updated automatically if you change
your code. The way this works is by instructing make to read an external makefile, via the line

-include ${Group0_DEP}

Group0_DEP has been calculated (see the top of the template) to mirror your set of source files.
If you are compiling in CFG=debug mode, for example...

Group0_SRC entries

Group0_DEP entries

Source1.cpp

deps.debug/Group0_Source1.d

Source2.cpp

deps.debug/Group0_Source2.d

LibrarySource1.cpp

deps.debug/Group0_LibrarySource1.d

LibrarySource2.cpp

deps.debug/Group0_LibrarySource2.d

Names of external dependency files

So make is instructed to include these external makefiles (these .d files). When first invoked,
it notices that these files do not exist, but also realizes that it has a pattern rule
(the deps.$(CFG)/Group0_%.d: %.cpp line above) that instructs on how to create them.
It therefore executes these rules, which invoke gcc with -MM and -MP and automatically
create the dependency rules in the .d files. When these rules are finished, make
realizes that external makefiles have changed, and re-includes them - thus learning
of all source files dependencies.

Clean rule
This rule will clean dependencies, object files and binaries if you invoke make clean.

Multiple CPUs/cores
If the " | inform" was missing from the bin.$(CFG)/${TARGET}: ... rule, and you
tried to invoke make for multiple CPUs/cores with something like...

make -j2

...you'd find that
the first CPU would try the inform rule (displaying the message about CFG missing) while the other
would try to implement bin.$(CFG)/${TARGET}, which, with CFG missing, would fail!
The " | inform" tells make that this rule has an order dependency on rule inform.

Even though what you see here is for C++ code, the principles demonstrated can be very easily adapted to
other languages (dependency output, accessing source files via VPATH, etc).

What to do if you have auto-generated code

The previous template will cover the needs of the vast majority of coders. There are however those few,
those happy few, that after having written hundreds of thousands of lines, realize that it would
be much better if machines wrote some of them. And they learn about flex and bison and about ANLTR;
and they start writing Perl and Python scripts that actually write code for them...

...which is probably not what you want. 'roboCoder.pl' will run twice, whenever you change documentation.tex.
This might sound like a minor inconvenience, but if you use the "-j" options, you might jolly well have two
make instances running one roboCoder each...
All hell might break loose (racing conditions when roboCoder opens its output files, etc).

There's no point in repeating - please go and read the perfect description of the problem in automake's
documentation (in the automake's FAQ section, read the "Multiple Outputs" entry).

If you adopt the solutions described there and try to put them
to use in the template I offered above, you'll face a problem: calculation of the external dependencies
(the .d files described in the previous section) needs access to the .h/.c/.cpp
files generated, so the code generation must somehow run before the dependencies generation.
The dependencies generation, however, is based on the inclusion of external makefiles;
if you just add the 'codeGen' rule as a prerequisite of your 'applicationName', it won't do;
included makefiles are handled by make before any other rules. The only workaround
I can offer is to add your 'codeGen' rule, as an order dependency, on the .d files themselves:

The comments on this website require the use of JavaScript. Perhaps your browser isn't
JavaScript capable or the script is not being run for another reason. If you're
interested in reading the comments or leaving a comment behind please try again with a
different browser or from a different connection.