Add CMake system for checking for C++11 feature support

Create issue
Issue #1 resolved
Matt Williams created an issue

As finally decided at there is a simple way of generally detecting C++11 features in the compiler.

It should consist of

  • A CMake part which detects features based on try_run()
  • A config.h-type header files defining which features are available for the C++ code to use.

Comments (9)

  1. Matt Williams reporter
    • changed status to open

    I have started work on this and have a 'cmake-cxx11-detect' feature branch in progress locally.

  2. Matt Williams reporter

    This branch is now available at cmake-cxx11-detect. It works for me on a number of Linux machines but would it be possible for anyone (David?) to test it to make sure that the build runs fine and the CMake output is sensible.

  3. David Williams

    I've just done a quick test but I have to leave work now so I can have another look tomorrow. My initial observations:

    • It overwrites the recent projects list in Visual Studio so that all the entries read 'CMAKE_TRY_COMPILE'. Previously CMake would only overwrite the first entry in this list. I'm sure this isn't your fault, but maybe a bug report needs to go to the author?
    • Everything seems to build correctly on VS2010. All C++11 features are detected.
    • It does not build on VS2008 and there are many errors which I'll have to look at later. No C++11 features are detected. Does it work on Linux with a non-C++11 compiler?

    I'll investigate further when I get a chance.

  4. Matt Williams reporter

    It should work on both VS2008 and VS2010 (even technically VS2005 if we're supporting that still). However, not all features should be detected (in either version) as not all features are available in VS2010 (see this).

    The oldest compiler I have access to is GCC 4.3 (early 2008 and doesn't support a lot more than VS2008) and it correctly detects that most of the C++11 features are not available. It does not crash while doing so. Even on the newest compiler I have access to (GCC 4.7) not all features are there but it detects it correctly. When you have had a closer look, send me the errors produced and I'll look into it.

    What does the recent projects list normally show? Is it the recently built targets or something else?

  5. David Williams

    It occurs to me now that I might not have Boost installed on my work machine... so perhaps that was the issue. I don't remember it complaining about missing headers though. Anyway, it should become clearer when I have a chance to look at the output more carefully.

    As for the recent projects list, well that's just like in many applications where you go 'File->Recent Documents->...' for example. My understanding is that it is these are recently opened projects (i.e. those the user works with frequently) but it's possible that actually they are recently built (which might explain the bug). But to most users it is the same thing as they only build projects from within Visual Studio anyway.

    But actually, I'm having second thoughts about the benefits this system brings. We established that we need a fallback for people who don't use CMake, so that means we need to provide a default set of values for these various C++ feature defines. As I see it, these default values should be obtained using the kind of compiler version detection which we were using previously. Once we're at that point, it seems there isn't really worth using the configure time detection because it will just give the same results as our existing system.

    I can see it would be useful if there were a large number of C++11 features which we were (optionally) dependant on but we've only got a couple. Are there other benefits to this approach? It's still nice to see the #defines tidied and moved into the CompilerCapabilities.h but I'm not sure how much the configure-time detection actually improves on what we had before?

  6. David Williams

    Ok, there was a problem with Boost in develop as well. It's fixed by this commit: 78cdf9a

    With this change your feature branch does now work on VS2008 (but my thoughts above still stand...)

  7. David Williams

    I'm also now wondering whether these changes (whether driven by CMake or not) should be applied beyond C++11. My recent work has highlighted that there may be some standard C++ features which we would wish to enable or disable. For example:

    • Android does not support C++ exceptions which means we need a way to eliminate them from PolyVox, probably by using a macro to throw them (Ogre does something like this with OGRE_EXCEPT).

    • On Android passing '-std=c++11' is causing a compile error. I haven't looked into it much and maybe it can be fixed (could be related to gameplay) but I don't want to build boost for Android so I've commented out the static_asserts. Maybe it wold be useful to have a flag to disable these if I can't fix the compile errors.

    • In issue #7 I mentioned that a better assert() macro might be desirable, and we would need a way to enable/disable this.

    Perhaps there are other examples, I'm not sure yet. But it seems we could seperate which features are supported from what we actually want to use. For example, 'CompilerCapabilities.h' could list the features of the compiler (maybe determined by CMake or just by checking compiler versions), while 'Features.h' could specify which features the user actually wants. This could be edtied by hand or optionally created by CMake. A feature would only be used if it were both available and wanted.

    Well, I guess we can discuss this a bit over Christmas.

  8. David Williams

    Ok, I think this is all now working as expected with the exception that it's currently disabled on Visual Studio due to the problem with the 'Recent Projects' getting over written. So from my point of view we can now close this issue or set it to 'on hold' if we think the VS issue might get addressed in the future. Is there anything else you want to work on for it?

  9. David Williams

    This is an old issue - CMake is working for us now, the library is header-only anyway, and C++11 is widely supported and required.

  10. Log in to comment