cxx11-cmake-modules in kdereview

[Thiago Macieira]

On sexta-feira, 1 de março de 2013 19.25.40, Ivan Čukić wrote:
> One needed feature forgotten, so I'm starting with it:
> 
> Is it possible for cmake scripts to test the Qt defines?

Why do you need that? Are you adding source files conditionally, depending on 
whether the compiler supports certain features?

> 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

Easily done with #ifdef

>   - the service - needs some c++11 features

Use #error for what is mandatory.

>   - other things (runtime plugins) - might require more features
> CMake needs to be able to know which of these to compile.

#ifdef and make dummies of what doesn't work.

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

As I said, you're obviously not using a feature that doesn't exist. And your 
code will not suddenly start using it. If you miss a feature, just add it to 
qcompilerdetection.h.

> > 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 '...'?

Huh?

> 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 :)

If you need that feature, we can add.

For now, we treated 13 as insufficient. And I haven't tested 2012 SP1 yet, so we 
may be missing some defines for the update.

> > 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?

No. You will get that.

I meant that if Qt thinks the compiler does not support initializer lists, you 
can't use initializer lists with QList and QVector.

> 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?

> > 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.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130301/c1b6d2af/attachment.sig>