Re: [cmake-developers] c++ feature detection and usage requirements
Brad King wrote: BTW, I think a better name may be language features rather than compiler features because we are declaring features of language versions and variants, not of the compilers. I don't agree with that. We are enumerating/introspecting the features of the compiler. The fact that the compiler is following a standard for its features is/should be irrelevant to the interface, and to the list of features. I've seen a few projects debating the useless question of 'Can we use C++11 now?', which eventually or quickly turns into the useful question of 'What features can we use from our compiler, given our minimum requirements?'. That's actually the same question they've always had to ask. They didn't consider questions like 'can we use C++98 now?', but 'can we use member templates now?'. The answer often being 'Yes, if we don't support MSVC6 anymore - it does not have that feature'. Such a view also justifies using the non-language-standard MSVC 'sealed' keyword in place of 'final' for 'the final feature', as the features are compatible. There may be other cases of such compatibility from non-standard compiler- provided features (which influenced the standard presumably). It is only in the implementation that we need to deal with compiler support for the features. Contrarily I say, it is only in the implementation that we need to consider the language-standard support for the features, because that is where the implementation needs to know (for some compilers) the standard the feature was introduced in, in order to pass the correct -std= argument. The language standard does not appear in the interface I've proposed, because it is irrelevant. The only relevant information is the minimum compiler requirements of the project. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
On 09/02/2013 02:03 AM, Stephen Kelly wrote: Brad King wrote: I think a better name may be language features rather than compiler features I don't agree with that. [good arguments] Okay, agreed. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
Brad King wrote:
On 08/29/2013 11:14 AM, Stephen Kelly wrote:
Another option would be not to have the VERSION in the signature, but
always use CMAKE_MINIMUM_VERSION_REQUIRED to determine what to generate.
The content generated depends only on the features of the cmake binary
being run, so it relieves users of the need to additionally maintain the
VERSION here and figure out how that maps to their minimum cmake version.
A project may wish to update to a newer required CMake version for some
other feature but is not ready to port their header generation. We
could define the versions w.r.t. the CMake version and make VERSION
optional. If not present use CMAKE_MINIMUM_VERSION_REQUIRED. If
present then fail if VERSION is newer than CMAKE_MINIMUM_VERSION_REQUIRED.
I put an untested pseudo-code version of this in my compiler_features
branch. It turns out that in order to do this, the compiler features would
have to be listed independently of Modules/Compiler/${ID}.cmake. Otherwise I
wouldn't be able to check the MSVC features while using GNU.
Maybe they should be listed in Modules/CompilerFeatures/${ID}-${LANG}.cmake
instead?
We also need a plan to phase out support for ancient versions in the
future.
Any ideas on how to do that?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
On 08/30/2013 08:02 AM, Stephen Kelly wrote:
It turns out that in order to do this, the compiler features would
have to be listed independently of Modules/Compiler/${ID}.cmake. Otherwise I
wouldn't be able to check the MSVC features while using GNU.
Maybe they should be listed in Modules/CompilerFeatures/${ID}-${LANG}.cmake
instead?
Why do you need to check features of a compiler not currently enabled?
Without being enabled we don't even know what version of the other
compiler to check.
I thought the idea was to specify in target_compiler_features the
features needed so they would be published in the target interface.
Then whatever compiler is used can have its feature set tested against
the requirements. This would work both in-project and in consumers, no?
We also need a plan to phase out support for ancient versions in the
future.
Any ideas on how to do that?
Perhaps we can document for each value of CMAKE_MINIMUM_VERSION_REQUIRED
the oldest VERSION value supported. That way it is up to the project
author to update VERSION and port code when bumping the minimum required
version of CMake. It will allow us to move forward but give projects
a long grace period.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
Brad King wrote:
On 08/30/2013 08:02 AM, Stephen Kelly wrote:
It turns out that in order to do this, the compiler features would
have to be listed independently of Modules/Compiler/${ID}.cmake.
Otherwise I wouldn't be able to check the MSVC features while using GNU.
Maybe they should be listed in
Modules/CompilerFeatures/${ID}-${LANG}.cmake instead?
Why do you need to check features of a compiler not currently enabled?
Without being enabled we don't even know what version of the other
compiler to check.
CMake has the information for all compilers, and the idea was to use that
information to generate a header for use with all of them.
Stephen Kelly wrote:
The header file would have the preprocessor tests and version checks for
the known compilers. That is, the generated header file would be the same
on all platforms, and would look something like qcompilerdetection.h, but
with a customizable prefix for the macros.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7655
However, thinking about it again, I think you're right that that is not
necessary. The built package and generated header is compiler/platform
specific anyway, unlike qcompilerdetection.h, which is a source file
identical in the packages for all platforms.
I thought the idea was to specify in target_compiler_features the
features needed so they would be published in the target interface.
Then whatever compiler is used can have its feature set tested against
the requirements. This would work both in-project and in consumers, no?
Yes, I went on something of a tangent here.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
On 08/30/2013 08:15 AM, Stephen Kelly wrote: However, thinking about it again, I think you're right that that is not necessary. Okay, it can always be factored out into separate files later anyway. I thought the idea was to specify in target_compiler_features the features needed so they would be published in the target interface. Then whatever compiler is used can have its feature set tested against the requirements. This would work both in-project and in consumers, no? Yes, I went on something of a tangent here. BTW, I think a better name may be language features rather than compiler features because we are declaring features of language versions and variants, not of the compilers. It is only in the implementation that we need to deal with compiler support for the features. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
On 08/28/2013 10:29 AM, Stephen Kelly wrote:
at least parts of KWIML should fit into this discussion too
[snip]
If instead projects distribute their own copies then we have
the option of changing the API and it is up to them to deal with it when
updating.
Yes. That's what I propose too.
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
)
Not quite. A newer CMake would have to write a compatible header
from this command. The current design of KWSys and KWIML is that
their source should be directly copied into the project source
(perhaps with various scripts to run updates). We can change them
as much as we want and projects will decide when they can update.
Each version of their source only has to work with one version
of the library. With an interface like the above many versions
of CMake would have to work with the same version of the project
source.
Yes, versioning is a good idea to think about.
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
VERSION 3
)
This could help somewhat because we could change what is produced
by a newer version while still knowing how to generate the old
version. The version argument must be required.
Rather than a single versioned header we should also consider
asking the caller to list the information and features needed.
That way a project can expose a header without more information
than they want to support.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
Brad King wrote:
Yes, versioning is a good idea to think about.
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
VERSION 3
)
This could help somewhat because we could change what is produced
by a newer version while still knowing how to generate the old
version. The version argument must be required.
Ok, I see what you mean.
Another option would be not to have the VERSION in the signature, but always
use CMAKE_MINIMUM_VERSION_REQUIRED to determine what to generate.
The content generated depends only on the features of the cmake binary being
run, so it relieves users of the need to additionally maintain the VERSION
here and figure out how that maps to their minimum cmake version.
Rather than a single versioned header we should also consider
asking the caller to list the information and features needed.
That way a project can expose a header without more information
than they want to support.
Yes, good idea.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
On 08/29/2013 11:14 AM, Stephen Kelly wrote: Another option would be not to have the VERSION in the signature, but always use CMAKE_MINIMUM_VERSION_REQUIRED to determine what to generate. The content generated depends only on the features of the cmake binary being run, so it relieves users of the need to additionally maintain the VERSION here and figure out how that maps to their minimum cmake version. A project may wish to update to a newer required CMake version for some other feature but is not ready to port their header generation. We could define the versions w.r.t. the CMake version and make VERSION optional. If not present use CMAKE_MINIMUM_VERSION_REQUIRED. If present then fail if VERSION is newer than CMAKE_MINIMUM_VERSION_REQUIRED. We also need a plan to phase out support for ancient versions in the future. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
On 08/27/2013 05:56 PM, Stephen Kelly wrote: I don't think the topic should be merged as-is because of the problems with the interface we know about so far. If you merge it and we also merge the interface which we agree to be better, we'll have two competing interfaces. I don't plan to merge it to master. I was saying that the work Eike has done so far is a very valuable source of information and experience with all the different platforms. and the expected results and will be useful for you to write a more complete solution. I'm sure Eike can do it too. Or at least get started with encoding the detection results into platform files and refactoring the detection code out of the find module so it can be used from the command. Can you propose a specific representation of this information in the platform files? If you get one feature done then perhaps Eike can fill in the rest of the details using the knowledge he's gained from his work so far. Or, even better, include(DetectCompilerFeature) # Checks CMAKE_CXX_COMPILER_FEATURES first as above and try_compile # only if needed. detect_compiler_feature(final HAVE_FINAL) Yes, though I'd like to hear other ideas for names. I also still think there should be a way for CMake to write a header file In the past we've avoided providing any kind of library with CMake, even a header-only one. GenerateExportHeader and FortranCInterface are precedent for generating headers that abstract platform-specific details. However, they only provide preprocessor definitions, not actual code. The header file would have the preprocessor tests and version checks for the known compilers. That is, the generated header file would be the same on all platforms, and would look something like qcompilerdetection.h, but with a customizable prefix for the macros. [snip] For is_convertible etc, there is a BSD licensed type_traits compatibility header here, which Qt 5 uses too and which could be distributed with CMake: I'm a bit hesitant to provide such a library header but the knowledge it encodes could reduce a lot of duplication across projects. Similarly, I've been tempted to provide KWIML in CMake distributions: http://cmake.org/gitweb?p=cmake.git;a=tree;f=Utilities/KWIML;hb=v2.8.11.2 to provide abstracted C fundamental type information macros and eliminate a large chunk of check_type_size calls. In both cases I'm hesitant for reasons of maintenance difficulty and commitment to backward compatibility in the API. If instead projects distribute their own copies then we have the option of changing the API and it is up to them to deal with it when updating. Perhaps this concern could be mitigated by the fact that we're generating the headers driven by calls to a module function. If the calls specified some kind of interface version then we would have a path for changing things. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
Brad King wrote:
On 08/27/2013 05:56 PM, Stephen Kelly wrote:
and the expected results and will be useful for you to
write a more complete solution.
I'm sure Eike can do it too. Or at least get started with encoding the
detection results into platform files and refactoring the detection code
out of the find module so it can be used from the command.
Can you propose a specific representation of this information in the
platform
files? If you get one feature done then perhaps Eike can fill in the rest
of the details using the knowledge he's gained from his work so far.
I propose refactoring the information into lists similar to what I did here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7746
I've pushed a compiler_features branch to my clone with a slightly more
advanced implementation.
I also still think there should be a way for CMake to write a header file
In the past we've avoided providing any kind of library with CMake, even a
header-only one. GenerateExportHeader and FortranCInterface are precedent
for generating headers that abstract platform-specific details. However,
they only provide preprocessor definitions, not actual code.
The header file would have the preprocessor tests and version checks for
the known compilers. That is, the generated header file would be the same
on all platforms, and would look something like qcompilerdetection.h, but
with a customizable prefix for the macros.
[snip]
For is_convertible etc, there is a BSD licensed type_traits compatibility
header here, which Qt 5 uses too and which could be distributed with
CMake:
I'm a bit hesitant to provide such a library header but the knowledge it
encodes could reduce a lot of duplication across projects.
I understand. With this 'C++11' discussion, I think of it more as a request
for CMake to make it easier to 'normalize compiler features' by somehow
using a define for things like FINAL and OVERRIDE and others, as the Qt and
Boost (and libcxx) systems do.
Of course, the compiler features need to be well defined in name and meaning
in CMake documentation somewhere.
Thinking about it like that led me to think of member_templates as a
compiler feature (common now, but MSVC6 didn't support them IIRC). The same
thought process leads me to think convenience for creating a header is a
good idea, for normalization purposes. As you said, there is some precedent.
Similarly,
I've been tempted to provide KWIML in CMake distributions:
http://cmake.org/gitweb?p=cmake.git;a=tree;f=Utilities/KWIML;hb=v2.8.11.2
to provide abstracted C fundamental type information macros and eliminate
a large chunk of check_type_size calls.
At least the @KWIML@_INT_INT#_C(c) is part of a 'normalization'. Qt provides
qint32, qint64 etc for the same purpose.
So, at least parts of KWIML should fit into this discussion too, as I see
it.
In both cases I'm hesitant for
reasons of maintenance difficulty and commitment to backward compatibility
in the API. If instead projects distribute their own copies then we have
the option of changing the API and it is up to them to deal with it when
updating.
Yes. That's what I propose too.
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
)
install(FILES
${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
${CMAKE_CURRENT_BINARY_DIR}/grantlee_export.h
DESTINATION include/
)
Perhaps this concern could be mitigated by the fact that we're generating
the headers driven by calls to a module function. If the calls specified
some kind of interface version then we would have a path for changing
things.
Yes, versioning is a good idea to think about. I haven't thought about that
yet.
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
VERSION 3
)
perhaps?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements (was: Please review CXXFeatures.cmake)
On 08/15/2013 08:37 AM, Stephen Kelly wrote: target_compiler_feature(target PUBLIC|PRIVATE REQUIRED feature1 [feature2 ...]) target_compiler_feature(target PUBLIC|PRIVATE OPTIONAL feature DEFINE define_name) Doesn't this require the language (CXX) to be specified somewhere? Perhaps the feature names should start with lang_ e.g. CXX_final. This is better in many noteworthy ways to the cxx11 topic in the stage. Brad, do you have any response to any part of anything I wrote about that topic? The detection of features available for a given compiler and the usage requirements to require/enable them are orthogonal issues on the implementation side but may overlap in the CMake interface. I like your proposed target_compiler_feature feature for the latter. As for detection, I like that Eike's solution will work without hard-coding knowledge for every compiler. I also like hard-coding the answers for known compilers whose id/version can be reliably detected to avoid needless try_compile calls on every project. Furthermore, your argument about partial implementations of features versus the documented later version introducing them is important. It is also nice to have it builtin to the platform information modules for use with target_compiler_feature. I'd like to see a solution that hard-codes the answers when known but also knows when it does not know and can run a detection step. This will be tricky because the platform files are too early to use try_compile so some kind of on-demand check may be needed. Ideas? I think Eike's topic will be a fantastic reference for the test case code and the expected results and will be useful for you to write a more complete solution. I like the target_compiler_feature syntax better than find_package(CXXFeatures), but something like the latter may be needed to make CMake-time decisions based on available features rather than waiting until preprocessing time. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
Brad King wrote:
On 08/15/2013 08:37 AM, Stephen Kelly wrote:
target_compiler_feature(target PUBLIC|PRIVATE
REQUIRED feature1 [feature2 ...])
target_compiler_feature(target PUBLIC|PRIVATE
OPTIONAL feature DEFINE define_name)
Doesn't this require the language (CXX) to be specified somewhere?
Perhaps the feature names should start with lang_ e.g. CXX_final.
I considered that, and I considered adding LANG lang to the command
signatures, and I considered naming the command with the language
(target_cxx_compiler_feature).
I didn't pick one, partly because it's a relatively minor detail we can
decide on after the larger issues below are resolved.
This is better in many noteworthy ways to the cxx11 topic in the stage.
Brad, do you have any response to any part of anything I wrote about that
topic?
The detection of features available for a given compiler and the
usage requirements to require/enable them are orthogonal issues
on the implementation side but may overlap in the CMake interface.
Yes. Even if we ignore the usage requirements angle, there are enough
reasons to not accept the currently proposed interface in the topic though.
I like your proposed target_compiler_feature feature for the latter.
Great.
As for detection, I like that Eike's solution will work without
hard-coding knowledge for every compiler. I also like hard-coding
the answers for known compilers whose id/version can be reliably
detected to avoid needless try_compile calls on every project.
Yes.
Furthermore, your argument about partial implementations of features
versus the documented later version introducing them is important.
Yes.
It is also nice to have it builtin to the platform information
modules for use with target_compiler_feature. I'd like to see a
solution that hard-codes the answers when known but also knows when
it does not know and can run a detection step.
Yes.
This will be tricky
because the platform files are too early to use try_compile so some
kind of on-demand check may be needed. Ideas?
That should be easy. Encode them into the platform files where known, and
implement target_compiler_feature to run a detection if
CMAKE_CXX_COMPILER_FEATURES is not set.
I think Eike's topic will be a fantastic reference for the test
case code
I agree that Tests/Module/FindCXXFeatures/CMakeLists.txt is a useful
reference. However, I don't think the interface in the topic should be
merged into master. We agree that target_compiler_feature is a better
interface, and hopefully Eike does too.
Eikes interface has some problems which I noted before here which make it
useless for libraries (or at least too incomplete to be useful) because the
result of the feature tests can't be used in public header files:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7715
Additionally, there is a 'cross platform trap' in the topic as it is
currently. Someone implementing a project on Windows using MSVC might write
this (assuming they were creating an executable, not a library because of
the above problem):
find_package(CXXFeatures)
if (CXXFeatures_class_override_final_FOUND)
add_definitions(-DGrantlee_FINAL=final)
endif()
It looks cross-platform, but it is not.
When they port the code to GCC, they need to add the ${CXX11_COMPILER_FLAGS}
somewhere (using the modern add_compile_options? No, using CMAKE_CXX_FLAGS
because it is _FLAGS).
My proposed interface does not have that problem because adding the compile
option for -std=c++11 (or -std=c++1y) is set internally.
As you said though, the detection code and the detection results encoded
into the tests are orthogonal to the interface issues. I think those parts
should be kept and refactored.
I don't think the topic should be merged as-is because of the problems with
the interface we know about so far. If you merge it and we also merge the
interface which we agree to be better, we'll have two competing interfaces.
and the expected results and will be useful for you to
write a more complete solution.
I'm sure Eike can do it too. Or at least get started with encoding the
detection results into platform files and refactoring the detection code out
of the find module so it can be used from the command.
I like the target_compiler_feature
syntax better than find_package(CXXFeatures), but something like the
latter may be needed to make CMake-time decisions based on available
features rather than waiting until preprocessing time.
Users could do the same as I suggest the target_compiler_feature does:
if (CMAKE_CXX_COMPILER_FEATURES)
list(FIND CMAKE_CXX_COMPILER_FEATURES final idx)
if(idx EQUAL -1)
set(HAVE_FINAL 0)
else()
set(HAVE_FINAL 1)
endif()
else()
include(DetectCompilerFeature)
detect_compiler_feature(final HAVE_FINAL)
endif()
if(HAVE_FINAL)
# ...
endif()
Or, even better,
include(DetectCompilerFeature)
# Checks
