Stephen Kelly wrote: > Rolf Eike Beer wrote: > >> Given that you're gathering the versions of each feature availability > >> anyway, and given that boost.config and qcompilerdetection.h have the > >> same information, there is no need for all users of the module to run all > >> these try_compiles for all projects. Think of the energy waste :)! > >> > >> I suggest you use CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION to > >> hardcode the features. You could even do so for known compilers, and > >> leave the try_compile stuff for not-known compilers if you really want > >> to, but I don't think that's worthwhile maintenance. > > > > We already found out that this is a bad idea for Apple, > > No we didn't :). > > The AppleClang vs VanillaClang version issue is something that needs to be > solved anyway.
The "which c++ lib is used" one, too. So you can only score one point, either this one or the one below ;) > > I still don't > > completely get it right for g++ and XL, and it isn't the way that CMake > > works for other things (I'm thinking of e.g. OpenMP). > > > > And > > qcompilerdetection.h is a good example of how I would not want it, last > > time I looked they just deactivated every feature on Clang. > > I don't know what you're talking about, but I am certain you're mistaken in > a simple interpretation of what you wrote. And I don't get what you write, but that is probably my fault. Anyway, I have looked into the header again, and the stuff seems to have been in there since it was split out of qglobal.h. So whatever I saw or think to have seen was probably wrong. But my point is still: if I have neither boost, nor Qt, nor Clang in the project I need a fallback solution anyway. So I could just always use this. > >> 4) > >> > >> The COMPILE_OPTIONS for clang+apple might have to include -stdlib=libc++ > >> for binary compatibility reasons if any of the dependencies use c++11 std > >> library API in their interface and use libc++. > >> > >> See what I wrote about that here: > >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5813 > > > > I don't see how this is different with and without C++11, so how does it > > affect this module in a way that would not affect the user anyway? > > You might have to investigate, for example, how system c++ libraries are > compiled. I'm not familiar enough with APPLE to know what kind of c++ > libraries it comes with. Again, how does that affect this module? What system library to use should be specified globally, in a way that try_compile also honors, no? I mean otherwise anything relying on try_compile is broken. For now I simply assume that try_compile get's the same library add_executable or whatever would also get, so the results of try_compile will be whatever the user can use. Eike --
signature.asc
Description: This is a digitally signed message part.
-- 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
