Am Freitag, 28. März 2014, 16:16:49 schrieb Stephen Kelly: > Hi, > > The target_compile_features topic in my clone is almost ready to merge to > next. > > Here are some remaining issues to discuss: > > 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.
> 2) Unavailable features
>
> There will be some set of features supported by CMake.
>
> Each tuple of {compiler id, compiler version, lang standard, extensions}
> will have some subset of those features available.
>
> If CMake is executed on a target which requires a particular feature, and
> CMake knows that the particular feature is not supported by the compiler id
> and version (with any extra flags), CMake reports an error.
>
> Recording that a {compiler id, compiler version} supports a particular
> feature is fairly easy, as is done in my topic already.
>
> 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)"?
> 3) Maintenance
>
> If CMake learns a cxx_partial_template_specialization feature in the future,
> the cxx_no_features feature would be removed for MSVC71 and
> cxx_partial_template_specialization added. That means that someone
> (preferably with direct access to MSVC71) needs to maintain the list of
> features for that {compiler id, compiler version} as the list of features
> known to CMake grows.
>
> This is more difficult maintenance to do for compilers which are no longer
> widely available or common.
[...]
> 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. If the
compiler features are unknown (i.e. the compiler support var is undefined) then
just run the compiletests and use whatever is the outcome. Have a way to force
CMake to use the tests instead of the hardcoded list. This will allow things
to work in case of new CMake versions (new features) with a feature list that
was not updated or if some vendor fscks up their version stuff. It would also
be a good testcase: everything hardcoded must be detected, otherwise our list
is broken (or the testcase).
> 4) All available features use-case
No idea. You are already far beyond what I would need with your stuff.
Eike
signature.asc
Description: This is a digitally signed message part.
-- 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
