Re: [Development] Breaking up QtPlatformSupport
On Wed, Mar 14, 2012 at 11:07:56AM +1000, ext Lincoln Ramsay wrote: On 03/12/2012 11:56 PM, ext Thiago Macieira wrote: qmake does not add a dependency on the .a file, so the other target doesn't get relinked. Qtopia had a large number of .a files and this hit us hard so we devised a workaround. i find this all quite academical. qmake is known to have utterly broken dependencies, and creating specific workarounds only creates a false feeling of safety. the universal workaround is configuring ccache and cleaning every time. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Breaking up QtPlatformSupport
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. Ah, now I see. This is where the missmatch is. QPA is by definition private apis that might change. It will stay like that for Qt 5. Maybe for Qt 6 we'r so confident that we might lock it down. Normally I define it like so: There is absolutely no abi, what so ever. You cant expect to take a plugin built with one sha, to be built with another sha... So 5.0 plugins will not work with 5.0.1 plugins. There is also no API guarantee. That means we won't break api just because we like to, but it also means it CAN change. Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Breaking up QtPlatformSupport
On 03/12/2012 11:56 PM, ext Thiago Macieira wrote:
qmake does not add a dependency on the .a file, so the other target doesn't
get
relinked.
Qtopia had a large number of .a files and this hit us hard so we devised
a workaround.
# A function to create explicit dependencies in a Makefile
defineTest(create_raw_dependency) {
var=$$1
dep=$$2
eval($${var}.depends*=\$$dep)
export($${var}.depends)
QMAKE_EXTRA_TARGETS*=$$var
export(QMAKE_EXTRA_TARGETS)
}
# relink our binary when foo.a changes
create_raw_dependency($$TARGET, /path/to/foo.a)
This literally gave us a rule in the Makefile like this:
mybin: /path/to/foo.a
Luckily, make doesn't care if you have multiple rules for a product,
as long as only one of them executes commands.
I doubt this works on non-Makefile projects though. Possibly not even on
non-GNU make. Probably easier to just have qmake generate the dependency
itself :)
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Breaking up QtPlatformSupport
On Sun, Mar 11, 2012 at 05:59:16PM +0100, ext Thiago Macieira wrote: This will be hard to do with qmake, so the easier way out is to remove the .a altogether and use .pri files only. well, there is also the option to split it into multiple .a files which have their own dependency lists. the increasingly lump approach of that library doesn't look very elegant anyway. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Breaking up QtPlatformSupport
This will be hard to do with qmake, so the easier way out is to remove the .a altogether and use .pri files only. That requires moving the Wayland platform plugin back into qtbase. Pretty please with sugar on top, do NOT do this. I understand that you only see the Wayland side of things, But there are loads of people interested in not having their plugin in the Qt source code. Using the pri approach is STUPID! The hacks you will force upon people is just not nice! We have been there, and we don't want to go back. Lets just keep/add again the -l flags, and let configure figure out if their going to be included or not. Building platform plugins outside the Qt source tree IS a usecase we'r going to support. Not only because of QtWayland but because there might be someone developing ie. an ios plugin that they don't want to have inside QtBase. People might have special HW that where they just write a plugin to do special ioctl to controll the display. We don't want all plugins to be in QtBase but more importantly we can expect all plugins to be in QtBase. Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Breaking up QtPlatformSupport
On 3/12/12 9:31 AM, ext Jørgen Lind jorgen.l...@nokia.com wrote: This will be hard to do with qmake, so the easier way out is to remove the .a altogether and use .pri files only. That requires moving the Wayland platform plugin back into qtbase. Pretty please with sugar on top, do NOT do this. I understand that you only see the Wayland side of things, But there are loads of people interested in not having their plugin in the Qt source code. Using the pri approach is STUPID! The hacks you will force upon people is just not nice! We have been there, and we don't want to go back. Lets just keep/add again the -l flags, and let configure figure out if their going to be included or not. Building platform plugins outside the Qt source tree IS a usecase we'r going to support. Not only because of QtWayland but because there might be someone developing ie. an ios plugin that they don't want to have inside QtBase. People might have special HW that where they just write a plugin to do special ioctl to controll the display. We don't want all plugins to be in QtBase but more importantly we can expect all plugins to be in QtBase. I have to agree with Joergen. We simply can't expect all platform plugins to live in QtBase. I also agree that we need a fix for plugins having undefined symbols, but we'll have to find a different way that forcing everything to live in qtbase. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Breaking up QtPlatformSupport
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.sor...@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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Breaking up QtPlatformSupport
On segunda-feira, 12 de março de 2012 15.23.33, Simon Hausmann wrote: 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 That statement does not match the fact that it's a static lib with only private headers. As I said before, if this is essential, we should consider *proper* public API. Keeping it like it is qualifies as hack. -- 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
Re: [Development] Breaking up QtPlatformSupport
On Mar 12, 2012, at 11:24 AM, ext Thiago Macieira wrote: On segunda-feira, 12 de março de 2012 09.31.11, Jørgen Lind wrote: This will be hard to do with qmake, so the easier way out is to remove the .a altogether and use .pri files only. That requires moving the Wayland platform plugin back into qtbase. Pretty please with sugar on top, do NOT do this. I understand that you only see the Wayland side of things, But there are loads of people interested in not having their plugin in the Qt source code. Using the pri approach is STUPID! The hacks you will force upon people is just not nice! We have been there, and we don't want to go back. Lets just keep/add again the -l flags, and let configure figure out if their going to be included or not. Building platform plugins outside the Qt source tree IS a usecase we'r going to support. Not only because of QtWayland but because there might be someone developing ie. an ios plugin that they don't want to have inside QtBase. People might have special HW that where they just write a plugin to do special ioctl to controll the display. We don't want all plugins to be in QtBase but more importantly we can expect all plugins to be in QtBase. 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. cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Breaking up QtPlatformSupport
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
[Development] Breaking up QtPlatformSupport
Hello After the alpha, I'd like to dismantle the QtPlatformSupport library and fix it properly. It should be broken up into smaller libraries or back into .pri files to be included. I know this is not going to be a popular change, but please bear with me on the explanation: Due to a mistake in the Qt buildsystem, the -Wl,--no-undefined is not used in plugin builds. This has led many plugins to be linked with undefined symbols because the necessary libraries were missing. In turn, that leads to surprising errors at runtime, like the application reporting that no platform plugins are present when libqxcb.so is clearly present. QtPlatformSupport was initially a bunch of .pri files that were included from plugins and caused code to be built and linked into the plugins. The mistake in forgetting the dependent libraries was already present in those .pri files. Then QtPlatformSupport was made into a convenience static lib (that is, a static library linked to a dynamic Qt, meant to be linked into another dynamic lib or plugin). Unlike any other convenience library out there, QtPlatformSupport is not meant to be used as a whole: plugins only need part of it. When I re-added support for -Wl,--no-undefined, I noticed that many plugins failed to link because the dependent libs were missing. So I proceeded to add those libs. Either way, with those libs being listed in .pri files inside QtPlatformSupport, all plugins linking to QtPlatformSupport link to those libs. That includes stupid things like the directfb plugin linking to the X11 libs. To make matters worse, a well-intentioned change (change 18023[1]) removed the libs from the .pri files. That, of course, meant that the plugins would fail to load unless the libs are listed in the plugins' .pro files. That change was made. However, the plugins STILL DON'T LINK with -Wl,--no-undefined. The reason for that is because QtPlatformSupport is a static library: the order of libraries listed in the command-line is relevant. qmake does the right thing when the libraries are listed as dependent in the libQtPlatformSupport.prl file. I asked ossi on IRC and we cannot find a way to set the library order to the right one, unless the libs are listed in the .pri .LIBS. Conclusion: since the libs must be listed when creating the static lib, the only way to avoid having DirectFB link to X11 is to break up QtPlatformSupport into smaller libs. This will be hard to do with qmake, so the easier way out is to remove the .a altogether and use .pri files only. That requires moving the Wayland platform plugin back into qtbase. [1] https://codereview.qt-project.org/18023 -- 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
