[cmake-developers] Please review CXXFeatures.cmake

[Rolf Eike Beer]

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
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20130805/aac3e617/attachment.sig>