On 04/07/2014 01:04 PM, Stephen Kelly wrote:
>>> 2) Unavailable features
>>> The distinction between "this compiler version supports an empty subset
>>> of the features known to CMake" and "we have not tested the features of
>>> this version of the compiler" is not quite so easy.
>
> I vaguely prefer being more explicit by using a non-feature-feature, but
> this can be deferred for the moment anyway.
This will need to be resolved now that the initial topic is in master.
Is this an implementation difficulty or are you just trying to decide
what interface a project should use to detect the distinction?
We need to be sure that adding knowledge of features for a particular
{id, version} combination that did not previously have them did not
does not cause projects to stop building. If CMake errors out only
when it knows the compiler does not have a requested feature but not
when it knows about no features from a {id, version} combination then
just filling out the table could stop projects from building that
used to happen to work.
I think we should reverse our earlier decision and go ahead and add
an error whenever a feature is requested that we do not know *is*
supported for the current {id, version}. This will make filling out
the feature table be monotonically decreasing in the number of error
cases projects can encounter. It will also encourage people to help
make the table complete.
We just need to find a reasonable path forward for projects that want
bleeding edge features if available but also want to be able to build
with tools for which CMake has not learned any feature tests. Could
these projects simply query CMAKE_CXX_COMPILE_FEATURES before making
something a build/usage requirement?
>>> Do we need to require some kind of maintenance commitment from people who
>>> want to add the first feature for a {compiler id, version} tuple, like is
>>> currently required for adding new modules?
>>
>> I would go for my initial approach: have a compile-test for it.
>
> I recall that seemed like a non-solution when this was discussed before. I
> think the problem is that the compile-test we write may not exercise all of
> the edge cases which may be relevant to a compiler version, such as
> undocumented cxx_constexpr support in GNU 4.5.
IIRC Boost.Config has a script one can run to populate everything for
a previously unseen compiler. Perhaps we can provide something like
that for filling out feature availability tables.
I think one invariant we need to maintain is that if CMake knows any
feature tests for a given {id, version} it needs to know all of them.
Whenever a new known feature is added then a test for it must be
added to all {id, version} combinations that know about any features.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
