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
