On 06/27/2011 07:07 PM, Rolf Eike Beer wrote:
> Michael Hertling wrote:
>
>> SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c89.c
>> PROPERTIES COMPILE_FLAGS ${CMAKE_C_DIALECT_C89})
>> SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c99.c
>> PROPERTIES COMPILE_FLAGS ${CMAKE_C_DIALECT_C99})
>> ADD_LIBRARY(c89 c89.c)
>> ADD_LIBRARY(c99 c99.c)
>>
>> It issues the supported C dialects and the contents of the associated
>> dialect variables, and the c89.c and c99.c source files are compiled
>> with the correct flags. Of course, the CMAKE_C_DIALECT_<DIALECT>
>> variables can also be appended to the CMAKE_C_FLAGS[_<CONFIG>]
>> variables instead of the COMPILE_FLAGS source file property.
>
> With a bit of thinking I would suggest a slightly different way. Don't add
> specific compiler flags for that source file. Tell CMake that this sourcefile
> uses
> a specific language dialect:
>
> SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c89.c
> PROPERTIES LANGUAGE_DIALECT C89)
>
> Then let CMake internally do the fiddling with the compile flags. This would
> have a few benefits:
>
> -if e.g. the language flags need to be passed first to the compiler CMake can
> assure this
> -colliding flags can be detected by the underlying implementation
> -if we ever get support for e.g. 2 different C compilers things like the Sun
> (was it Sun? Too lazy to look up) compilers can be supported as CMake would
> just call the right compiler binary
> -this can easily change in any direction later if someone decides the
> underlying implementation needs a change
>
> Well, basically all points target in the same direction, no? It seperates the
> switch logic from the user and allow greater flexibility in the
> implementation.
> With the expense that probably some C++ code of CMake needs to be touched.
>
> Eike
Currently, one can add a new compiler - a real one as well as a wrapper
script - without rebuilding CMake itself, and that's highly convenient.
Is it feasible to implement such a, say, flag management along with the
necessary knowlegde base, i.e. information about which flags to add/re-
move/modify/reorder, in pure CMake code? Do you intent to include flags
concerning dialect strictness? E.g., GCC with "-std=c99" accepts legacy
C89 constructs, but doesn't recognize inline assembly introduced by the
"asm" keyword; other compilers might handle this differently. So, does
the C99 dialect property means strict C99, lenient C99 w.r.t. C89, C99
with common extensions etc., and will the decision be enforced? Pardon
for these critical questions, but I think they - and possibly others -
should be considered when contemplating a comprehensive management of
language dialect flags. The numerous compilers with their vast number
of flags - even just the dialect-related ones - make me believe that
this would be a nearly impossible undertaking. The approach with the
__language_dialects() function, in contrast, aims at a quite simple
mechanism doing simple things via a simple interface and is easy to
implement without narrowing the user's freedom more than necessary.
Additionally, it allows to query the basic dialect capabilities of
the compiler in charge and to edit the dialect flags in the cache
similar to the configuration flags CMAKE_<LANG>_FLAGS_<CONFIG>.
Regards,
Michael
_______________________________________________
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
