[cmake-developers] compile_feature test results
Brad King
brad.king at kitware.com
Mon Nov 18 14:46:29 EST 2013
On 11/12/2013 10:10 PM, Stephen Kelly wrote:
> Brad King wrote:
>> 1. Revert the target_compile_features topic until this is resolved.
>
> Done. Rebased to master and pushed to my clone.
Okay, thanks.
>> 2. Create a new topic that adds a *test* in which you build the
>> new infrastructure. (This way all the trial and error will be
>> isolated to a single test and other topics can proceed without
>> interference.)
>>
>> 3. Once the test works everywhere, the actual infrastructure can
>> be ported over to the Modules directory and the test can just
>> exercise it.
>
> I'm not claiming these tasks, so they're up for grabs (Eike?).
I took a quick look at the compiler id infrastructure's execution of
the compiler and I'm not confident it can be reliably generalized as
I proposed above. However, I have a new approach to suggest.
Even though the "Compiler/<id>-<lang>" modules are where we specify
information about available language variants, there is no reason
that record_compiler_features has to run inside them. We just need
the information to be available by the time the language is enabled.
In the compiler information modules we only need to construct a list
of tests to be run and delay running them until later when the
"CMakeTest<LANG>Compiler" module is loaded. At this point we have
enough information for a real try_compile. This is how the ABI is
determined (see calls to CMAKE_DETERMINE_COMPILER_ABI).
You can take an approach similar to CMAKE_DETERMINE_COMPILER_ABI,
perhaps called CMAKE_DETERMINE_COMPILE_FEATURES, in order to do the
try_compile calls necessary to detect available features. We should
need just one such call per language, just as with the ABI.
-Brad
More information about the cmake-developers
mailing list