> 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 _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
