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

Andreas Mohr andi at lisas.de
Mon May 7 14:58:45 EDT 2012


Hi,

> Date: Mon, 7 May 2012 12:22:27 -0500
> From: Robert Dailey <rcdailey.lists at gmail.com>
> Subject: Re: [CMake] Setting COMPILE_FLAGS property on a target in
> 	only	debug?
> To: Michael Wild <themiwi at gmail.com>
> Cc: cmake at cmake.org
> Message-ID:
> 	<CAHd499CMhRnMuPmzzCdpjRd3sF6=H19Ev9Vbim9PauNBJ8FA9A at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Mon, May 7, 2012 at 10:37 AM, Robert Dailey <rcdailey.lists at gmail.com>wrote:
> I'm going to desperately need configuration-aware COMPILE_FLAGS, because in
> Visual Studio, I have cache variables that enable certain features, like
> edit & continue, minimal rebuild, etc... features that are not compatible
> with /O2 (optimizations on). Since CMake has no choice but to enable these
> MSVC features in all configurations, my release builds don't work, and the
> user will be required to disable these features via cache variable every
> time they want to build release, which is unnecessary.

Let me add my 2c (European or Chinese):

same here - if CMake had had that feature, supporting it within
vcproj2cmake (which does a reverse mapping from Visual Studio to CMake
and thus very obviously would have good use for this capability)
would have been doable in a snap.

I'd like to add one more dimension to it:
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".
And for the sometimes desired per-configuration-type (**dynamic**) way
of handling this CMake currently doesn't have much (if any) support.
For platform-/build_type-hardcoded generators such as Ninja or Makefile
that's of course usually fine, but...

[from a recent analysis I believe CMake's VS generator simply fills in
platform as the setting of the current host platform - whereas heavily
cross-compiling setups certainly are at issue with the questionable handling
of filling in platform cfg from HOST-side rather than TARGET-side attributes]


Thus spake someone who still hasn't found the time to implement
at least a semi-usable/-supported (static) CMake way
of platform configuration type dependent switching in his V2C converter... :-P
(1 year old bug report and counting)

Andreas Mohr


More information about the CMake mailing list