How to create targets for individual debug and release build directories?

Question

I am looking for suggestions for the correct handling of individual debugging and release subdirectories in a recursive makefile system that uses the $ (SUBDIRS) target, as described in the gnumake manual, to use the make target subgoals in (source code).

In particular, I am interested in possible strategies for implementing goals, such as "everything", "clean", "realclean", etc., which either accept one of the trees or must work on both trees, causing a problem.

Our current make files use the COMPILETYPE variable, which is set to Debug (the default) or Release (the "release" target), which properly builds, but clears and does work only in the default debug tree. Passing the COMPILETYPE variable becomes awkward because how and how to do it depends on the value of the actual target.

Answer 1

One option is to have specific goals in subdirectories for each type of assembly. Therefore, if you do "do everything" at the top level, it looks at COMPILETYPE and calls "make all-debug" or "make all-release" as necessary.

Alternatively, you can set the COMPILETYPE environment variable at the top level and associate each page file with this.

The real solution is not to do recursive make, but to include make files in subdirectories in the top-level file. This will allow you to easily create in a different directory than the source lives, so you can have the build_debug and build_release directories. It also allows you to work in parallel (make -j). See Recursive analysis is considered harmful for a full explanation.

Answer 2

If you participated in your Makefiles regarding the use of the $ (COMPILETYPE) variable to reference the appropriate assembly directory in all of your rules, the rules that generate the object files, the clean / dist / etc rules, you should be fine.

In one project that I was working on, we had a variable $ (BUILD), which was set (equivalent) to build- (COMPILETYPE), which simplified the rules, because all the rules could just refer to $ (BUILD), for example, clean will be rm -rf $ (BUILD).

As long as you use $ (MAKE) to invoke sub-make (and using GNU make), you can automatically export the COMPILETYPE variable to all sub-brands without doing anything special. See the relevant section of the GNU manual for more information.

Some other options:

• Replace reassembly when the compiler flags change, adding a dependency for all objects in the metafile that tracks the last used set of compiler flags. See For example, how Git manages object files .
• If you use autoconf / automake, you can easily use a separate assembly layout collector for your different assembly types. for example, cd /scratch/build/$COMPILETYPE && $srcdir/configure --mode=$COMPILETYPE && make , which will output the build type from Make files and into configure (where you will need to add some support to specify the necessary build flags based on the value --mode in your configure.ac )

If you give more specific examples of your real rules, you might get a few more specific suggestions.