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
signature.asc
Description: This is a digitally signed message part.