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
