[CMake] Why do people need so much control over details of their build?

Brad King brad.king at kitware.com
Tue Mar 30 16:33:59 EDT 2010


David.Karr at L-3COM.COM wrote:
> I very much sympathize with your aversion to re-introducing all this
> fine-grained control

Okay, your argument presents sufficient motivation to consider this
extra control for build trees.  See below ("Moving forward...").

> The command-line-and-templates alternative (as implemented in the VS 6
> generator) had at least three major benefits.

That design has been a PITA for years.  I've been tempted to go back and
re-implement the generator to drop use of templates.  If it weren't for
all the embedded systems compilers that only exist as plugins to VS 6
then we may have already dropped support for the generator.

> One is that the CMake C++ source code is free from all these
> vendor-specific details, which makes CMake itself more maintainable.

The VS 10 generator finally solved this.  All the flag -> option mapping
is automatically generated from xml files describing the options that
come with the compiler.

Moving forward, we'll need two changes:

(1) AFAIK the <target>.idb file can be anywhere so long as it is in
the same place every time the linker runs.  Correct?  Therefore we
can hide it away in the <target>.dir/ directory in the build tree.

(2) Introduce a new setting similar to the runtime output directory:

  CMAKE_SYMBOL_OUTPUT_DIRECTORY[_<CONFIG>]
        ^^^^^^ as in "debug symbol"; suggestions for name?

If set then it controls where .pdb files go and is ignored on other
platforms.  It will need to be implemented for Makefiles (for NMake)
and also for the VS IDE generators.

I have no time to look at this for a while, but I'm happy to help you
get started on a patch.  Take a look at Source/cmTarget.cxx:

(a) cmTarget::ComputeOutputDir takes a boolean to switch between the
real binary and its import library.  This can be converted to an
enumeration to add the symbol file too.

(b) Make a similar change to cmTarget::GetDirectory.

(c) Add the corresponding field to cmTarget::OutputInfo.

Then update the calls to cmTarget::GetDirectory in the generators
for computing .pdb file locations.

-Brad


More information about the CMake mailing list