[Qt5-feedback] What is the Qt view of targets, and is it the same as QtSDKs ?

[Attila Csipa]

> If you end up with massive depths of #ifdef's then you likely have a
> problem in your design/implementation. The original version of my log

The defaul qmlviewer.cpp can give you a premonition on how things look like in 
mobile applications (keep in mind that one is essentially just Symbian and 
desktop). Add MeeGo, Maemo, Anna, Harmattan, Android in there and the thing 
starts looking like the phantom of the opera without the mask. Something 
similar happens once you go down the dark path of multimediakit. And that's 
just the c++ code, where are the UI/QML/firmware/packaging specifics that I 
can't even apply the qmake scopes and #ifdefs to ? Important note - I'm not 
saying Qt should solve/wrap all these for me - but there HAS to be an easier 
way to deal with/manage the breadth of supported targets THROUGHOUT the 
development chain, not just C++ code.

This is not something new, people have noted some of these pains before - see 
http://thpmaemo.blogspot.com/2010/10/qt-write-once-ifdef-everywhere.html

> Distros mainly focus on aspects that apply to everyone. Qt (and KDE btw)
> have to think of multiple platforms, including providing those platform
> specific bits that the distros (who mainly use Linux or Embedded Linux
> which are essentially the same) don't have to (at least as much).

That was the original point - the QtSDK generated installable packages for 
various versions of Symbian, Maemo, MeeGo... In the old days of spitting out a 
binary a Qt based project owner could say 'well if something doesn't work for 
Ubuntu, their problem, fix it downstream'. However, nowadays there is a shift - 
it's not the Symbian/Maemo/MeeGo/etc maintainers/engineers who adapt packages, 
it's up to the *upstream* project developer to provide packages for all of 
these (as he/she is the one publishing it to Ovi, AppUp, Extras, etc), hence 
the trouble (do really I need to know how .sis files are made ? debian 
packaging ? spec files ? policy requirements for all those ?). Plus, desktops 
are fairly stable in terms of backwards compatibility and usually have a 
fairly good upgrade path wrt to Qt versions. With mobile devices what you get 
is what you have (rarely do you get the luxury of distributing your preferred 
version/patches of Qt).

Currently, the fight against excessive #ifdeffing is done by not providing 
#defines and scopes (see the opinions on Q_WS_MAEMO5 and the recent examples of 
harmattan and meego), which makes things even worse (you're not even able to 
do the SOURCES += part in your example or device/distro specific classes 
without additional/custom scopes).

> Introducing something like applying patches to header files based on which
> platform you are on is not a solution - that only complicates it as you
> never truly know what your final header file is going to look like. KISS
> is your friend.

In my hypothetical/argumentative alternative (auto-apply diff when switching 
targets) you would see *exactly* how your final target would look like, with 
the added benefit that it would equally well for packaging, pro, QML files, etc. 
Your example didn't convince me :) as for all #ifdef intents and purposes. 
source (with ifdefs) + preprocessor = source + diff + preprocessor.


Best regards,
Attila Csipa