[Development] Breaking up QtPlatformSupport

[Simon Hausmann]

On Monday, March 12, 2012 02:56:02 PM ext Thiago Macieira wrote:
> On segunda-feira, 12 de março de 2012 11.50.17, morten.sorvig at Nokia.com 
wrote:
> > On Mar 12, 2012, at 11:24 AM, ext Thiago Macieira wrote:
> > > Anyway, either way this library will be gone. The most likely solution
> > > is
> > > that we will break it up into many smaller .a libraries.
> > 
> > One other thing I've noticed is that linking agains an .a library breaks
> > incremental builds: touch qfontengine_coretext.mm, and the following
> > top-level build will not re-link the cocoa platform plugin.
> 
> That's not just Mac. It happens on all platforms.
> 
> qmake does not add a dependency on the .a file, so the other target doesn't
> get relinked.
> 
> > The best way to fix this seems to just include the relevant platform
> > support .pri files directly in the cocoa plugin (see
> > http://codereview.qt-project.org/#change,16107).
> 
> Which is what I'd prefer, but Jørgen is strongly against.
> 
> > Since nobody seems to want multiple .a files, what if we compromise and
> > allow both approaches? In-source platform plugins can use the .pri files
> > directly while out-of-source plugins link against libplatformsuppport.
> 
> It doesn't solve my problem. Those out-of-source plugins would not link
> properly.
> 
> The way I see it, our options are:
> 
> 1) do nothing (not an option, just for comparison)
> 	=> no plugins link properly
> 	=> relinking broken
> 
> 2) add the missing LIBS to platformsupport
> 	=> plugins link to libs they don't need
> 	=> relinking broken

The relinking could be fixed with POST_TARGETDEPS, here's what we use in WebKit 
to achieve the same:

        win32-msvc*|wince*|win32-icc {
            POST_TARGETDEPS += $${path}$${QMAKE_DIR_SEP}$${target}.lib
        } else {
            POST_TARGETDEPS += $${path}$${QMAKE_DIR_SEP}lib$${target}.a
        }

The unnecessary linkage could be fixed by using an extra variable. For example
platformsupport.pri could include .pri files in all the modules and 
platformsupport.pro as well as the individual plugins using platformsupport 
could include platformsupport.pri.

Then for example the .pri file in the font-config platform font database could 
use PLATFORMLIBS += -lfontconfig

and the actual plugins do

LIBS += $$PLATFORMLIBS
 
> 3) break platformsupport into smaller libs
> 	=> lots of work
> 	=> links properly
> 	=> relinking still broken
> 
> 4) remove the libs completely
> 	=> links properly
> 	=> relinking fixed
> 	=> plugins outside of qtbase cannot use platformsupport

The thing about platformsupport is that it is _not_ a convenience library, it 
is at this moment absolutely _essential_ for writing a real world platform 
plugin ;(


Simon