[Development] Breaking up QtPlatformSupport

Thiago Macieira thiago.macieira at intel.com
Mon Mar 12 17:15:50 CET 2012


On segunda-feira, 12 de março de 2012 15.28.01, gunnar.sletta at nokia.com wrote:
> > Building plugins outside of QtBase will continue to be permitted, provided
> > they don't use QtPlatformSupport. That library is just convenience for us.
> > There is absolutely no public API there. If there are things needed by
> > many
> > plugins, we should consider making proper, public API instead.
> 
> Not only will building platform plugins outside QtBase be permitted, it will
> in fact be the primary usecase if we consider Qt's future on embedded
> devices. Most good adaptations will want to do something hardware specific.
> It is not just convenience for us inside QtBase.
> 
> We can talk about making it into a nicer API in a future version of Qt, but
> for Qt 5, we should keep it as it is.

Understood. I'm not against out-of-qtbase plugins. I am against forcing them 
to use private and changing API like QtPlatformSupport.

Either way, we need to fix the linking. As I explained in more than one email, 
as long as one big QtPlatformSupport library exists, we will have broken code. 
Unless someone volunteers Ossi to somehow hack qmake to support this 
behaviour.

And do it again once we switch buildsystems in Qt 5.1 or 5.2, since "mandatory 
dependencies are optional" is not usually a feature.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120312/a8439e9a/attachment.sig>


More information about the Development mailing list