On segunda-feira, 12 de março de 2012 15.28.01, gunnar.sle...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
