Brad King wrote:
> On 08/30/2013 08:02 AM, Stephen Kelly wrote:
>> It turns out that in order to do this, the compiler features would
>> have to be listed independently of Modules/Compiler/${ID}.cmake.
>> Otherwise I wouldn't be able to check the MSVC features while using GNU.
>>
>> Maybe they should be listed in
>> Modules/CompilerFeatures/${ID}-${LANG}.cmake instead?
>
> Why do you need to check features of a compiler not currently enabled?
> Without being enabled we don't even know what version of the other
> compiler to check.
CMake has the information for all compilers, and the idea was to use that
information to generate a header for use with all of them.
Stephen Kelly wrote:
> The header file would have the preprocessor tests and version checks for
> the known compilers. That is, the generated header file would be the same
> on all platforms, and would look something like qcompilerdetection.h, but
> with a customizable prefix for the macros.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7655
However, thinking about it again, I think you're right that that is not
necessary. The built package and generated header is compiler/platform
specific anyway, unlike qcompilerdetection.h, which is a source file
identical in the packages for all platforms.
>
> I thought the idea was to specify in target_compiler_features the
> features needed so they would be published in the target interface.
> Then whatever compiler is used can have its feature set tested against
> the requirements. This would work both in-project and in consumers, no?
Yes, I went on something of a tangent here.
Thanks,
Steve.
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
