[CMake] No <LANG>_FLAGS_<CONFIG> target property.

[Óscar Fuentes]

Michael Hertling <mhertling at online.de>
writes:

>>> So you add global compiler flags which are not meant to be global? A usual 
>>> person would say: "then do not set them globally!".
>>> It's really that simple...
>> 
>> No, I want to replace those automatically setted by CMake.
>
> AFAIK, CMake doesn't set compilation flags by itself, perhaps unless a
> specific toolchain/platform file enforces this. Rather, the flags are
> roughly set up as follows - for C compilations:
>
> 1) CMAKE_C_FLAGS for all configurations; explicitly set or initialized
>    by the CFLAGS environment variable when CMake is run initially.
> 2) Addition of CMAKE_C_FLAGS_<CONFIG> for the configuration.
> 3) Addition of COMPILE_FLAGS source/target properties.
>
> If you set neither CFLAGS/CMAKE_C_FLAGS nor CMAKE_C_FLAGS_<CONFIG> nor
> COMPILE_FLAGS, your source files should be compiled without any flags,

Say CMake, say a toolchain/platform file, once a project is started it
comes with the "standard" flags for compiling in the chosen mode (debug,
release, ...) and, IIRC, in some cases some other flags which are
deemed as "good to have" are added too.

> so the art is to specify the latters such that each source file will
> be compiled with the correct/desired set of them.
>
> However, you're right insofar that there's no possibility to specify
> flags which will be used solely for a certain target *and* a certain
> configuration, but in my experience, this is almost never necessary.
> Do you have a special problem in this regard, i.e. a flag that must
> be activated for one target in one configuration only?

Generally speaking, I had a case for building the same sources with
different flags. One project I maintain (LLVM) compiles an utility that
is used to generate files later in the same build. The problem is VC++
in Debug configurations: the debug VC++ runtime makes the utility to
perform excruciatingly slow. Someone was annoyed enough by that to
create a patch that builds the utility and one library it uses in
optimized mode when the user activates an option. The ugly part of the
patch was a trick for building the library used by the utility twice:
one with the usual Debug configuration (required because that library is
used by everything else on the project) and another with optimization
flags. He resorted to creating an extra directory for building the
optimized version, because CMAKE_C*_FLAGS* affects all targets defined
on the same CMakeLists.txt file.

Fortunately our problem can be easily solved on a totally different way,
but I was surprised by the lack of target properties for setting the
compiler flags.

[snip]

> Finally, if you really need to drop a flag from a compilation command
> and can't avoid its addition by other means, you could use one of the
> RULE_LAUNCH_COMPILE properties to intercept the compiler command and
> adjust the command line to whatever is necessary [2]. Regrettably,
> this is restricted to the Makefile generators.

IDE support is required. Whenever I see a feature restricted to Makefile
generators, I know it is not useful to me. I wish the docs showed this
restriction at the top of the description of the feature :-/

> Alternatively, you
> might modify the CMAKE_C_COMPILE_OBJECT rule variable within the
> affected directories, especially w.r.t. the <FLAGS> placeholder,
> see [3].

I cannot access the link because gmane mangled it, but I guess that
CMAKE_C_COMPILE_OBJECT has the same restriction as CMAKE_C_FLAGS (it
acts with the same value over all targets defined on the same
CMakeLists.txt).

[snip]