cxx11-cmake-modules in kdereview

[Ivan Čukić]

One needed feature forgotten, so I'm starting with it:

Is it possible for cmake scripts to test the Qt defines?

Namely, the kactivities repository is consisted of a few parts that have (as 
previously agreed) different c++ feature requirements
  - the library - compilable with any Qt/KDElibs supported compiler so that 
users of the library don't need to use modern compilers
  - the service - needs some c++11 features
  - other things (runtime plugins) - might require more features
CMake needs to be able to know which of these to compile.

> Right, they are documented only in the header. You have my word that the 
> Q_COMPILER_* defines will be maintained.

This is good^Wgreat to know.

> It's there: Q_COMPILER_NULLPTR, as well as Q_NULLPTR.

Which Qt version? I've grepped all includes of 4.8.2 and can not find NULLPTR 
at all.

(^ from the later email, got you are talking about Qt5)

Still, the issue of extensibility remains. Though, Qt5 covers everything we 
currently need.

> Both are compile-time. The Clang ones are even based on Clang itself
> declaring whether it supports them, with the __has_feature extension.

Wasn't talking about compile-time.
I meant this:
    #if defined(Q_CC_MSVC) && _MSC_VER >= 1600
       define stuff...
Versus:
   Does this compile '...'?

This can be problematic. IIRC, the latest version of MSVC supports variadic 
templates, as long as they don't have more than 13 arguments (don't remember 
the actual limit, but I remember there was one). For some projects, it can be 
useful even like that, and I don't think Qt will have 
Q_COMPILER_VARIADIC_TEMPLATES_SHORTER_THAN_13 macro :)


> Besides, if you want to check whether the given feature was enabled in Qt,
> you need to use the same define that was used to enable it. Doing two
> separate checks, for example for initializer lists, could spell trouble. If

This is a nice point if I understood it correctly  -  so, if Qt is compiled 
with a compiler that didn't support initializer lists, we will not get the 
macro stating our new compiler does?

Though, from my POV it is both great and bad - great to be able to know what 
Qt supports, but bad if I don't intend to use the features in Qt that depend 
on NXXX feature of the compiler, but I need it for my code.

> What's more, they're there. Why not use them?

If it turns out that those cover all the use-cases we need, ok, we can use 
them (though I'm not thrilled about maintaining the copy of Qt5 defines in all 
projects). But, even if we go that way, at some point we might need to revise 
this decision and to recreate this module because we need some additional 
test.


Cheerio,
Ivan




-- 
You know, there are many people in the country today who,
through no fault of their own, are sane. Some of them were born sane.
Some of them became sane later in their lives...
  -- Monty Python's Flying Circus