On 03/15/2011 06:13 AM, Óscar Fuentes wrote:
> Michael Hertling <mhertl...@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.
Yes, but these "standard" flags are the default values of the various
CMAKE_<LANG>_FLAGS[_<CONFIG>] variables which you can (re)set during
the project's (re)configuration. Nevertheless, at first, they apply
to all of the project's targets, indeed.
>> 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.
Probably, I would have run the same path. While the utility might in
fact be built with SET(CMAKE_C_FLAGS_DEBUG ${CMAKE_C_FLAGS_RELEASE})
after all ADD_SUBDIRECTORY() commands in its CMakeLists.txt are done,
the prerequisite library must be built twice in different directories
to limit the modified set of flags to one of them - possible but ugly.
> 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.
Perhaps, this would be worth a feature request, but I suppose there's
a fundamental difficulty: Due to the diverse possibilities to specify
a target's compilation flags - CMake/environment variables, target/
source properties - the final set is possibly not composed until the
project's configuration is finished, i.e. they are possibly not kept
centrally. So, how should one access them in their entirety? Anyway,
a configuration-specific version of the COMPILE_FLAGS properties is
off the ground [1].
>> 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).
Yes, that's right, and the effect of CMAKE_C_COMPILE_OBJECT can be
limited in the same manner as for CMAKE_C_FLAGS[_<CONFIG>], i.e. by
placing it after the ADD_SUBDIRECTORY() commands. However, it still
applies to all targets in the current CMakeLists.txt file. Moreover,
I've been told that CMAKE_C_COMPILE_OBJECT et al. are available for
Makefile generators only although neither the documentation nor the
Wiki mentiones this.
Regards,
Michael
[1] http://www.cmake.org/Bug/view.php?id=6493
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
