[Development] Request for new Playground Repo

[André Pönitz]

On Wed, Nov 20, 2013 at 07:51:34PM +0000, Knoll Lars wrote:
> On 20/11/13 20:36, "Andrew Wooster" <awooster at blackberry.com> wrote:
> 
> >Hi, I'd like to request the creation of a new playground repository.
> >
> >Name: BlackBerry Extras
> >
> >Description: A repository for creating BlackBerry specific APIs that are
> >useful for implementing Qt functionality.
> >
> >Let me know if there are any questions.
> 
> If the purpose is the same as the other QPlatformExtras modules, I¹m happy
> to add it.

I am not.

The general approach is wrong, for several reasons:

1. Splitting the platform extras already on the module level means that
everybody who wants to use some of the extras even buried behind #ifdef's
somewhere deep in his code has to add platform specific conditional code like

   !isEmpty(QT.x11extras.name) {
        QT += x11extras
        DEFINES += I_CAN_USE_X11EXTRAS
    } else {
        warning("x11extras module not found, ....")
    }

to his buildsystem(s), for each of the platforms he want to "fully"
support. This is a maintanance burden not just for the buildsystem itself
but also extends to conditional packaging/installation.

2. The setup is inherently fragile as only part of the code is used, and part
not even checked on a specific developer's machine at a time, bearing the
risk of the classic "compile fix" or "CI" "ping pong".

3. The approach does not scale as it does not offer a natural place for
features that are not available on all platforms, but on more then one.
Putting random sort-of-sharable code into qtbase is not a good alternative
either.


There is no perfect solution, but the further "down" the conditionals 
are in the code the less impact they have on all three aspects, and
the more code can be shared between the "backends".

Merging the platform into a single module with fat #ifdefs QT_OS_XYZ
in the headers would already alleviate the problem on the build system
level, and upwards (packaging...), while providing the same interface
to the actual code. That'd be a uniform improvemnt over the current setup.

Andre'