Rolf Eike Beer wrote:
>> 1) Extensions
>> I propose ignoring the granularity of XL and letting the user be more
>> granular if they wish (I think there's also granularity available with
>> GNU flags).
>
> I think just go for whatever is needed to get the requested features, if
> it enables more then it will be this way.
Yes.
>> 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.
>
> Maybe "if (DEFINED var)" vs. "if(VAR)"?
Perhaps.
I vaguely prefer being more explicit by using a non-feature-feature, but
this can be deferred for the moment anyway.
>> 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.
Anyway, my solution for now is to get a single point feature in to get the
infrastructure established, then extend the point to the vector of C++11
features for one compiler on one platform (GCC 4.8 on GNU).
Once that is in master, it will be possible to extend the supported feature
matrix along all the other dimensions (compiler extension features, C++98,
older GNU, other compilers, other platforms) at any point afterward,
preferably one step at a time to minimize dashboard chaos.
Of course, it is easier to get features into the CMAKE_CXX_KNOWN_FEATURES
list when there is only one compiler to test for on the dashboard. I'll add
one C++98 feature to establish the infrastructure, but I don't intend to be
exhaustive about C++98 features. If you or anyone else has an interest in
doing so, I'd recommend getting them in early.
Thanks,
Steve.
--
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
