Re: [cmake-developers] target_compile_features remaining issues
Brad King wrote: > On 04/22/2014 08:51 AM, Brad King wrote: >> We just need another interface to specify that the standard >> request is a strict requirement. > [snip] >> for projects that have this requirement it is better to fail >> due to a missing setting in CMake than work accidentally and fail later >> when CMake is updated. > [snip] >> Perhaps another boolean property like CXX_STANDARD_REQUIRED would work. > > Please extend the decay-language-version topic to add this option > and associated documentation. We need to make sure users are > aware that to be fully future-proof they need to use the > CXX_STANDARD_REQUIRED interface. Then projects can decide how > gracefully they want to decay language support. Ok, done. However, if it causes any dashboard trouble I'd prefer to back it out and defer it. It will trigger extra tests on platforms which I've been trying to ignore for the purposes of the compile features concept. 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
Re: [cmake-developers] target_compile_features remaining issues
On 04/22/2014 08:51 AM, Brad King wrote: > We just need another interface to specify that the standard > request is a strict requirement. [snip] > for projects that have this requirement it is better to fail > due to a missing setting in CMake than work accidentally and fail later > when CMake is updated. [snip] > Perhaps another boolean property like CXX_STANDARD_REQUIRED would work. Please extend the decay-language-version topic to add this option and associated documentation. We need to make sure users are aware that to be fully future-proof they need to use the CXX_STANDARD_REQUIRED interface. Then projects can decide how gracefully they want to decay language support. Thanks, -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
Re: [cmake-developers] target_compile_features remaining issues
On 04/21/2014 02:42 PM, Stephen Kelly wrote:
> Brad King wrote:
>
>> Later CMake learns about the -std=c++11 flag for that compiler and
>> honors the CXX_STANDARD request by passing it. Now the compiler
>> has its extensions disabled and the project fails to build. This
>> was due to an update in CMake, not the project.
>
> Is the same problem present with CMAKE_*_COMPILE_OPTIONS_{PIE,PIC,DLL} ?
Yes, but that is less fundamental than the language standard level.
>> We need a way for a project to say that it should not build unless
>> CMake knows how to nominally enable support for the given language
>> level.
>
> This requirement is inconsistent with what people keep asking me for (namely
> something like what the qmake CONFIG += c++11 does - enable a c++11 flag if
> known, and do nothing if not), and is inconsistent with the decay- topic.
Yes, and the CXX_STANDARD property in the decay- topic satisfies this
use case. We just need another interface to specify that the standard
request is a strict requirement.
> I think it be determined with code equivalent to
>
> if (target->GetProperty("CXX_STANDARD" == std::string("11")
>&& !makefile->GetDefinition("CMAKE_CXX11_STANDARD_COMPILE_OPTION"))
>{
>// FATAL_ERROR
>}
Yes, so long as we set CMAKE_CXX11_STANDARD_COMPILE_OPTION to an empty
string on the compilers that support C++11 by default, like VS 12 (2013).
> We would need to know the compile options of compilers supported by existing
> versions of CMake, and ensure that the option is recorded for new
> CompilerIds and new releases of existing compiler ids too.
Yes, but for projects that have this requirement it is better to fail
due to a missing setting in CMake than work accidentally and fail later
when CMake is updated. Even with a missing setting in CMake it will
typically be possible to work around it locally by adding the setting
to the cache.
> However, I guess two different interfaces are needed if you want to ensure
> the 'require some notion of C++11' concept.
Perhaps another boolean property like CXX_STANDARD_REQUIRED would work.
Thanks,
-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
Re: [cmake-developers] target_compile_features remaining issues
Brad King wrote:
> Later CMake learns about the -std=c++11 flag for that compiler and
> honors the CXX_STANDARD request by passing it. Now the compiler
> has its extensions disabled and the project fails to build. This
> was due to an update in CMake, not the project.
Is the same problem present with CMAKE_*_COMPILE_OPTIONS_{PIE,PIC,DLL} ?
> We need a way for a project to say that it should not build unless
> CMake knows how to nominally enable support for the given language
> level.
This requirement is inconsistent with what people keep asking me for (namely
something like what the qmake CONFIG += c++11 does - enable a c++11 flag if
known, and do nothing if not), and is inconsistent with the decay- topic.
I think it be determined with code equivalent to
if (target->GetProperty("CXX_STANDARD" == std::string("11")
&& !makefile->GetDefinition("CMAKE_CXX11_STANDARD_COMPILE_OPTION"))
{
// FATAL_ERROR
}
We would need to know the compile options of compilers supported by existing
versions of CMake, and ensure that the option is recorded for new
CompilerIds and new releases of existing compiler ids too.
However, I guess two different interfaces are needed if you want to ensure
the 'require some notion of C++11' concept.
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
Re: [cmake-developers] target_compile_features remaining issues
On 04/20/2014 03:57 AM, Stephen Kelly wrote: >> Perhaps we can have a feature name like "cxx_std_11" to require a >> given standard level with an error if it is not available. > > Which compilers would provide that feature? GCC 4.8.1 and Clang 3.4 > (complete support)? GCC 4.7 (First release after ratification. Has compile > flag -std=c++11)? GCC 4.3 (Has -std=c++0x)? MSVC? MSVC 2015 (speculative > full support)? MSVC 2010 (partial support)? MSVC 2008 (Has override > keyword)? Consider a project that writes set(CMAKE_CXX_STANDARD 11) and someone tries to build with a compiler for which CMake does not know about a -std=c++11 flag. Currently CMake generates no error and "decays" to build with no flag at all. Let's say the project happens to build without the flag because the compiler defaults to a hypothetical -std=ext11 flag. Furthermore the project code happens to (unintentionally) depend on that compiler's extensions to c++11 to compile. Everything appears to work. Later CMake learns about the -std=c++11 flag for that compiler and honors the CXX_STANDARD request by passing it. Now the compiler has its extensions disabled and the project fails to build. This was due to an update in CMake, not the project. We need a way for a project to say that it should not build unless CMake knows how to nominally enable support for the given language level. Within that level the project could do its own preprocessor tests or use WriteCompilerDetectionHeader to adapt to the subset of the language level the compiler actually supports. However, when CMake is asked to use a compiler it does not know supports the language level at all, it should be an error. -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
Re: [cmake-developers] target_compile_features remaining issues
Brad King wrote:
> On 04/15/2014 11:39 AM, Stephen Kelly wrote:
>>> 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}.
>>
>> Yes, I think that makes sense. Such an error can be relaxed in the future
>> if desired.
>
> The change proposed here:
>
> Features: Decay language flag if requested is not available.
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=93e7729d
>
> makes the CXX_STANDARD target property specify a request to be
> decayed rather than a requirement.
Actually it makes the request decay, rather than not decay.
That property does not communicate a requirement even before the decay-
patch.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9812
> What if a project really wants to require a given standard level?
That request is too non-granular. What does it mean? (In terms of compiler
versions)
> Perhaps we can have a feature name like "cxx_std_11" to require a
> given standard level with an error if it is not available.
Which compilers would provide that feature? GCC 4.8.1 and Clang 3.4
(complete support)? GCC 4.7 (First release after ratification. Has compile
flag -std=c++11)? GCC 4.3 (Has -std=c++0x)? MSVC? MSVC 2015 (speculative
full support)? MSVC 2010 (partial support)? MSVC 2008 (Has override
keyword)?
> Steve, how did you envision CXX_STANDARD, CXX_EXTENSIONS, and
> COMPILE_FEATURES to be used together by a project?
COMPILE_FEATURES specify requirements. As a side-effect of processing them,
the CXX_STANDARD and CXX_EXTENSIONS may be set. Those properties, if an
appropriate flag is known to represent them, cause a flag to be added to the
compile line.
http://www.steveire.com/cmake-future/manual/cmake-compile-features.7.html
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
Re: [cmake-developers] target_compile_features remaining issues
On 04/15/2014 11:39 AM, Stephen Kelly wrote:
>> 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}.
>
> Yes, I think that makes sense. Such an error can be relaxed in the future if
> desired.
The change proposed here:
Features: Decay language flag if requested is not available.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=93e7729d
makes the CXX_STANDARD target property specify a request to be
decayed rather than a requirement. What if a project really wants
to require a given standard level?
Perhaps we can have a feature name like "cxx_std_11" to require a
given standard level with an error if it is not available.
Steve, how did you envision CXX_STANDARD, CXX_EXTENSIONS, and
COMPILE_FEATURES to be used together by a project?
Thanks,
-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
Re: [cmake-developers] target_compile_features remaining issues
Brad King wrote:
> 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?
Only deciding the interface.
>
> 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.
Yes. An option would be to wrap the population of features for a compiler in
new CMake releases, where that feature is known to previous CMake releases,
in a CMAKE_MINIMUM_REQUIRED_VERSION check.
> 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.
Yes, I think that makes sense. Such an error can be relaxed in the future if
desired.
It might also give us something of a 'census' to find out what compilers
people care about to use with new CMake features and fill the table. Of
course, culture will also affect that anyway (A GNU user is more likely to
contribute than a MSVC user, probably), so probably not so useful.
> 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?
Yes.
if (CMAKE_CXX_COMPILE_FEATURES)
target_compile_features(tgt PRIVATE cxx_constexpr)
endif()
would work.
>
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.
Yes, I considered adding a separate mode to the CompileFeatures test to run
try_compiles of each source file there with each
CMAKE_CXX*_{STANDARD,EXTENSION}_COMPILE_OPTION. That could be used to create
a report, but not to generate the -FeatureTests.cmake file for checkin. If
you run such a script with GNU-4.7 now, you have to figure out how to merge
the output with the existing GNU-CXX-FeatureTests.cmake.
> 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.
Yes. I tried to get that across in the change to cmake-developer (in my
clone, not in next yet)
http://www.steveire.com/cmake-future/manual/cmake-developer.7.html#adding-compile-features
> 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.
Yes.
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
Re: [cmake-developers] target_compile_features remaining issues
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
Re: [cmake-developers] target_compile_features remaining issues
On 04/07/2014 01:04 PM, Stephen Kelly wrote: > 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. This is now in master as of: Merge topic 'cxx11-features' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8472ef24 -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
Re: [cmake-developers] target_compile_features remaining issues
On 10/04/14 09:46, Stephen Kelly wrote: > Alex Merry wrote: > >> On 28/03/14 15:16, Stephen Kelly wrote: >>> The target_compile_features topic in my clone is almost ready to merge to >>> next. >> >> Having looked through the docs for the topic, the thing that is missing >> that I'd like to see is a way (probably a variable) to specify the >> default enabled features for all targets in the project (or subdir). > > I guess the idiom for that would be a add_compile_features command which > populates a COMPILE_FEATURES directory property. See the COMPILE_OPTIONS > directory and target properties for comparison. Yep, that would work. Alex -- 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
Re: [cmake-developers] target_compile_features remaining issues
Am 10.04.2014 10:44, schrieb Stephen Kelly: Rolf Eike Beer wrote: Am 08.04.2014 11:43, schrieb Stephen Kelly: Rolf Eike Beer wrote: 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. Cool. I think it would be good to get the stuff that is enabled by the "-AA +hpxstd98" calls on HP-UX 11i into such a feature so we can make the "complex" testcase just select whatever is needed automatically instead of fiddling around to get the magic flags getting passed into that test to make the C++ compiler behave like something useful. Ok, I don't know anything about the features or flags of that compiler. What features do you have in mind to add? Working (IIRC), or anything in std namespace. Basically it looks like the old HP compiler needs +hpxstd98 as compile flag to behave like a C++98 compiler at all, likely because that compiler line is indeed older than 1998 and that simply is not the default as for later versions of that compiler. And the -AA flag is also needed for, uhm, something, at least CMake doesn't build without it. So far, features which have been added are related to the compiler (driver), not the standard library. I've deliberately not considered stdlib features because I don't know how much slower that would make the feature checks. You would have to run many compile tests. Currently, features are recorded by a single compilation which checks preprocessor defines. I'm not convinced this features system is the right tool to solve your HP stdlib problem. cxx_working_iostreams or cxx_working_stdlib are not features I envisioned adding when designing it. I suggest considering alternative solutions, such as simply adding both flags in the Compiler/HP.cmake file, a target property or a variable. I googled a bit around and reread the mails where I was told about that flags. Basically "-AA" says "use the new C++ lib", which is what we need. The "I need working and std namespace" is the result of +hpxstd98, which they call "advanced template support", or from the current point of view "C++98 compliant template support". This is really a compiler thing, adding -AA later if +hpxstd98 is needed would be simple by just looking at the compiler flags. From what we currently know these 2 flags are needed only together, but not because they are related. They are needed because the compilers that need them have default settings for both things (C++ lib, language support) that are just too old for what CMake requires. Eike -- 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
Re: [cmake-developers] target_compile_features remaining issues
Alex Merry wrote: > On 28/03/14 15:16, Stephen Kelly wrote: >> The target_compile_features topic in my clone is almost ready to merge to >> next. > > Having looked through the docs for the topic, the thing that is missing > that I'd like to see is a way (probably a variable) to specify the > default enabled features for all targets in the project (or subdir). I guess the idiom for that would be a add_compile_features command which populates a COMPILE_FEATURES directory property. See the COMPILE_OPTIONS directory and target properties for comparison. > In fact, that's sort of what I'd expect from CMAKE_CXX_COMPILE_FEATURES, > and I'd expect that functionality to be in something like > CMAKE_CXX_AVAILABLE_FEATURES or something. That seems like a fine name to me. 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
Re: [cmake-developers] target_compile_features remaining issues
Rolf Eike Beer wrote: > Am 08.04.2014 11:43, schrieb Stephen Kelly: >> Rolf Eike Beer wrote: >> 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. >>> >>> Cool. I think it would be good to get the stuff that is enabled by the >>> "-AA +hpxstd98" calls on HP-UX 11i into such a feature so we can make >>> the >>> "complex" testcase just select whatever is needed automatically >>> instead of >>> fiddling around to get the magic flags getting passed into that test >>> to >>> make the C++ compiler behave like something useful. >> >> Ok, I don't know anything about the features or flags of that compiler. >> >> What features do you have in mind to add? > > Working (IIRC), or anything in std namespace. Basically it > looks like the old HP compiler needs +hpxstd98 as compile flag to behave > like a C++98 compiler at all, likely because that compiler line is > indeed older than 1998 and that simply is not the default as for later > versions of that compiler. And the -AA flag is also needed for, uhm, > something, at least CMake doesn't build without it. So far, features which have been added are related to the compiler (driver), not the standard library. I've deliberately not considered stdlib features because I don't know how much slower that would make the feature checks. You would have to run many compile tests. Currently, features are recorded by a single compilation which checks preprocessor defines. I'm not convinced this features system is the right tool to solve your HP stdlib problem. cxx_working_iostreams or cxx_working_stdlib are not features I envisioned adding when designing it. I suggest considering alternative solutions, such as simply adding both flags in the Compiler/HP.cmake file, a target property or a variable. 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
Re: [cmake-developers] target_compile_features remaining issues
Am 08.04.2014 11:43, schrieb Stephen Kelly: Rolf Eike Beer wrote: 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. Cool. I think it would be good to get the stuff that is enabled by the "-AA +hpxstd98" calls on HP-UX 11i into such a feature so we can make the "complex" testcase just select whatever is needed automatically instead of fiddling around to get the magic flags getting passed into that test to make the C++ compiler behave like something useful. Ok, I don't know anything about the features or flags of that compiler. What features do you have in mind to add? Working (IIRC), or anything in std namespace. Basically it looks like the old HP compiler needs +hpxstd98 as compile flag to behave like a C++98 compiler at all, likely because that compiler line is indeed older than 1998 and that simply is not the default as for later versions of that compiler. And the -AA flag is also needed for, uhm, something, at least CMake doesn't build without it. Eike -- 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
Re: [cmake-developers] target_compile_features remaining issues
On 28/03/14 15:16, Stephen Kelly wrote: > The target_compile_features topic in my clone is almost ready to merge to > next. Having looked through the docs for the topic, the thing that is missing that I'd like to see is a way (probably a variable) to specify the default enabled features for all targets in the project (or subdir). In fact, that's sort of what I'd expect from CMAKE_CXX_COMPILE_FEATURES, and I'd expect that functionality to be in something like CMAKE_CXX_AVAILABLE_FEATURES or something. Alex -- 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
Re: [cmake-developers] target_compile_features remaining issues
Rolf Eike Beer wrote: >> 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. > > Cool. I think it would be good to get the stuff that is enabled by the > "-AA +hpxstd98" calls on HP-UX 11i into such a feature so we can make the > "complex" testcase just select whatever is needed automatically instead of > fiddling around to get the magic flags getting passed into that test to > make the C++ compiler behave like something useful. Ok, I don't know anything about the features or flags of that compiler. What features do you have in mind to add? 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
Re: [cmake-developers] target_compile_features remaining issues
> 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. Cool. I think it would be good to get the stuff that is enabled by the "-AA +hpxstd98" calls on HP-UX 11i into such a feature so we can make the "complex" testcase just select whatever is needed automatically instead of fiddling around to get the magic flags getting passed into that test to make the C++ compiler behave like something useful. 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
Re: [cmake-developers] target_compile_features remaining issues
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
Re: [cmake-developers] target_compile_features remaining issues
Rolf Eike Beer wrote: > 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. > > Because I just had to look into the module: the stuff in > CMakeBackwardCompatibilityCXX.cmake could probably be merged (at least in > parts) into the compile_features lists as things like ANSI for scoping is > a similar feature class like variadic templates or range based for loops. Perhaps. My interest is in features which differentiate contemporary compilers which I use - Recent GNU and MSVC C++11 features and extensions. That's what I'm going to focus on, but the design is intended to allow specifying features like the ansi for loops too. I'd say you can add that at some point when the rest of the infrastructure is defined and merged. 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
Re: [cmake-developers] target_compile_features remaining issues
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. Because I just had to look into the module: the stuff in CMakeBackwardCompatibilityCXX.cmake could probably be merged (at least in parts) into the compile_features lists as things like ANSI for scoping is a similar feature class like variadic templates or range based for loops. 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
Re: [cmake-developers] target_compile_features remaining issues
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
Re: [cmake-developers] target_compile_features remaining issues
Philipp Moeller wrote: > Hi Stephen, > > I'm not sure how this feature would fit in any CMake build system I > currently maintain. Thanks for your response. The topic is here https://gitorious.org/cmake/steveires-cmake/commits/target_compile_features and the manual I wrote for it is here: http://www.steveire.com/cmake-future/manual/cmake-compile-features.7.html Those links might answer some of your questions. 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
Re: [cmake-developers] target_compile_features remaining issues
Stephen Kelly writes: > Hi, > > The target_compile_features topic in my clone is almost ready to merge to > next. Hi Stephen, I'm not sure how this feature would fit in any CMake build system I currently maintain. How does it improve upon the current #ifdef tables provided by e.g. Boost.Config? How does it improve over C++14 __has_feature and __has_include? Also, I wont be able to drop Boost.Config (or my own configuration tables) when this feature arrives because users of my library without CMake should still get header-files configured for their compiler. I think this is also missing the common work-around macros (MY_LIBRARY_CONSTEXPR, MY_LIBRARY_LIBRARY_OVERRIDE, etc.) which are necessary to write code that works on multiple standards. Maybe I'm missing what this feature is supposed to achieve, but I can't see how this would serve my needs. What I would find useful if I could use CMake to write a configuration header with a customized prefix. write_compiler_configuration_header(my_lib output_path) and the resulting header would contain the entire #ifdef for feature availability. Of course, when a compiler feature is a hard requirement of a target (currently it often isn't) encoding it in the build system would be nice to have. [...snipped...] -- 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
Re: [cmake-developers] target_compile_features remaining issues
Stephen Kelly writes: > Hi, > > The target_compile_features topic in my clone is almost ready to merge to > next. [...snipped rest of the message...] Hi Stephen, I'm not sure how this feature would fit in any CMake build system I currently maintain. How does it improve upon the current #ifdef tables provided by e.g. Boost.Config? How does it improve over C++14 __has_feature and __has_include? Also, I wont be able to drop Boost.Config (or my own configuration tables) when this feature arrives because users of my library without CMake should still get header-files configured for their compiler. I think this is also missing the common work-around macros (MY_LIBRARY_CONSTEXPR, MY_LIBRARY_LIBRARY_OVERRIDE, etc.) which are necessary to write code that works on multiple standards. Maybe I'm missing what this feature is supposed to achieve, but I can't see how this would serve my needs. What I would find useful if I could use CMake to write a configuration header with a customized prefix. write_compiler_configuration_header(my_lib output_path) and the resulting header would contain the entire #ifdef for feature availability. Of course, when a compiler feature is a hard requirement of a target (currently it often isn't) encoding it in the build system would be nice to have. Cheers, Philipp -- 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
[cmake-developers] target_compile_features remaining issues
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
With GNU and Clang, standard C++ features are enabled with a compile flag
something like -std=c++98 or -std=c++11. Compiler specific extensions are
enabled with a flag like -std=c++98 or -std=gnu++11. It is a two-dimensional
system. One axis extends the C++ standard whose features are required, and
the other extends the compiler features.
With XL, compiler specific extensions are enabled with -qlanglvl=extended.
For GNU, Clang and XL, the compiler-specific extensions are enabled by
default.
http://pic.dhe.ibm.com/infocenter/lnxpcomp/v121v141/index.jsp?topic=%2Fcom.ibm.xlcpp121.linux.doc%2Flanguage_ref%2Fexts_general.html
The XL driver doesn't seem to be two dimensional in the same way as GNU.
That is, we can use -qlanglvl=extended0x to get the extensions *and*
the C++0x [sic] features. There doesn't seem to be a -qlanglvl=no-extended
to disable the compiler-specific extensions.
Because the XL driver offers more granularity in features that may be
enabled/disabled, it is possible to enable only the C++0x features by
specifying more flags.
COMPILER | CXX_STANDARD | CXX_EXTENSIONS | FLAG
GNU98 0-std=c++98
GNU98 1-std=gnu++98
Clang 98 0-std=c++98
Clang 98 1-std=gnu++98
XL 98 0[NA] [1]
XL 98 1-qlanglvl=extended
GNU11 0-std=c++11
GNU11 1-std=gnu++11
Clang 11 0-std=c++11
Clang 11 1-std=gnu++11
XL 11 0-qlanglvl=extended0x [2]
XL 11 1-qlanglvl=extended0x
GNU14 [3] 0-std=c++14
GNU14 1-std=gnu++14
Clang 14 0-std=c++14
Clang 14 1-std=gnu++14
XL 14 0-qlanglvl=extended14 [4]
XL 14 1-qlanglvl=extended14
[1] No known -qlanglvl=no-extended flag.
[2] Future versions of XL might enable the C++11 features by default. In
that case we would add no flags for this combination.
[3] CXX_STANDARD=14 allowed in a future CMake version, when it is ratified
and GNU/Clang support -std=c++14.
[4] Or whatever flag they choose to enable C++14 features.
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).
Does that have an impact on the order that built-in vs user flags are
specified in the compile commands?
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.
Currently my topic reports no error if there are no recorded features for a
compiler version. An error is only reported if the {compiler id, version}
is known to have features (which means someone must have investigated and
added them).
That means that if I try to use MSVC71 for example with a target which
requires cxx_constexpr, there will be no error reported by CMake, because
MSVC71 supports an empty subset of the current features known to CMake.
One way to enable that error would be to introduce a dummy cxx_no_features
feature for use with compilers known to have an empty subset of the features
known to CMake.
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.
The same requirement of maintaining the list of features is present for
contemporary compilers, but it is easier to maintain for compilers which
