[CMake] Setting COMPILE_FLAGS property on a target in only debug?

[Andreas Mohr]

Hi,

On Mon, May 07, 2012 at 07:27:53PM -0400, cmake-request at cmake.org wrote:
> Date: Mon, 07 May 2012 23:51:03 +0200
> From: Stephen Kelly <steveire at gmail.com>
> Subject: Re: [CMake] Setting COMPILE_FLAGS property on a target in
> 	only	debug?
> To: cmake at cmake.org
> Message-ID: <jo9g47$irq$1 at dough.gmane.org>
> Content-Type: text/plain; charset="ISO-8859-1"
> 
> Andreas Mohr wrote:
> > I'd think that Debug/Release isn't all that matters -
> > what discussions all too conveniently leave out (possibly even the KDE
> > Wiki-side target config discussion!) is platform-specific handling,
> > too (Win32 / Win64 / cross-compiles / ...).
> > After all, a full build declaration is "x64/Release", not merely
> > "Release". 
> 
> But what is the CMAKE_BUILD_TYPE in this case? Also, how do you deal with 
> these platform issues (Win32 / Win64 / cross-compiles / ...) currently?

THAT is the main question that non-configuration-types generator people keep asking :)
The crux is that on Ninja / Makefile you CMake-configure-run (plus generate)
a *static* Debug-specific *or* Release-specific build environment.
Whereas on those "alien" generators (IDEs)
you one-time generate a *static*, *combined* build env,
i.e. later *dynamically* switchable between Debug and Release
(and CMake then doesn't have anything to do with this aspect anymore -
that's being governed by VS "$(OutDir)" etc. variables).
"Macros for Build Commands and Properties"
  http://msdn.microsoft.com/en-us/library/c02as0cs%28v=vs.71%29.aspx
And that is the reason why CMAKE_CONFIGURATION_TYPES (list of dynamic configs)
vs. CMAKE_BUILD_TYPE (static setting) is inherently at odds with each other
(and incidently why e.g. there's obvious trouble
when trying to discover the binary file output directory statically within CMake scripts,
for the case of multi-config generators).


How I deal with these platform issues myself?
That's very easy: I don't [currently need to] in my build environment.
(don't ask...)

For the vcproj2cmake project in general, I'm about to implement a model
where the platform to be built for (gathered from the list of platforms
that was provided in the content of the Visual Studio project files)
can be hard-coded initially - chosen via a user-side CMake CACHE variable
(for relevant explanations see further below).

> Do you mean you want to run cmake once and then build multiple 
> configurations (at the same time?)?

Indeed - depending on the current *dynamically switchable*
configuration dialog setting of Debug vs. Release or some such.

> Instead of what I do which would be 
> 
> mkdir debug && cd debug
> cmake .. -DCMAKE_BUILD_TYPE=Debug
> make
> mkdir ../release && cd ../release
> cmake .. -DCMAKE_BUILD_TYPE=Release
> make
> 
> You want to build debug and release at the same time?

That's what *those* people (want to) do - not necessarily me. ;)


And - in addition to one dimension (Debug, Release, MinRelSize),
there's the other possibility of switching the build's TARGET platform
(Win32, x64, AnyCPU [.NET garbage collector garbage],
and perhaps other specifically set-up cross-compile TARGET platforms).
You usually specify both parts, i.e. go to x64/Release (or e.g. Win32/Debug)
at the very time you tell it the configuration to be subsequently built.



For CMake perhaps per-platform handling was never much of an issue,
since for static single-configuration generators this is as simple as
doing a
if(want_platform_a)
  ...
in CMake code, whereas for multi-config generator use
one might be able to use different (uncommon, weirdly combined)
build type names, e.g. x64_Release
(and the corresponding COMPILE_DEFINITIONS_X64_RELEASE etc. property names)
[not sure how CMake platform setup (CMake platform setup module files)
would be/is done in such a case though,
since one would have to runtime-switch toolchain i.e. compilers, too].


From a CMake POV on multi-configuration-capable generators
it's probably expected that once you generate a build environment,
you simply always end up with a build tree specific
to a single platform only (e.g. Win32).
And if someone does intend to additionally create builds
for another TARGET platform (cross-compile or some such),
then one does have to generate another separate
platform-specific build environment.
(whereas all these build trees *are* dynamically switchable in the
Debug/Release/... dimension).
And I don't know whether I can fault them for deciding on doing it like this
in CMake.

Andreas Mohr