[Development] Is Xlib a hard requirement for Qt5 xcb?
Shawn.Rutledge at digia.com
Mon Jul 29 09:49:41 CEST 2013
On 26 Jul 2013, at 11:19 PM, Nicolás Alvarez wrote:
> Hi everyone,
> I attempted to build Qt5 and KF5 in a minimal system, only installing
> dependencies when configure/cmake asks for them, in order to find bugs
> (such as missing dependency checks) in the build system. I was
> successful, in the sense that I found missing checks :)
> I'm configuring Qt with the options suggested in the KF5 wiki:
> ./configure -prefix $PWD/qtbase -opensource -developer-build
> -nomake tests -nomake examples -dbus -no-separate-debug-info -xcb -qpa
> xcb -no-gtkstyle -no-pch
> My minimal system does not have X11 development files (such as
> Xlib.h), but it does have XCB stuff.
> Compilation fails with:
> make: Entering directory `/home/nicolas/src/qt5/qtbase/src/widgets'
> util/qsystemtrayicon_x11.cpp:60:22: fatal error: X11/Xlib.h: No such
> file or directory
> make: Leaving directory `/home/nicolas/src/qt5/qtbase/src/widgets'
> make: Entering directory
> qxcbmime.cpp:49:23: fatal error: X11/Xutil.h: No such file or directory
> qxcbcursor.cpp:52:28: fatal error: X11/cursorfont.h: No such file or directory
> qxcbxsettings.cpp:46:36: fatal error: X11/extensions/XIproto.h: No
> such file or directory
> make: Leaving directory
> The question is: is Qt5/XCB *supposed* to work without Xlib? I got the
> feeling that there was some attempt to make it work, since some code
> is protected with #ifdef XCB_USE_XLIB checks (though perhaps that
> define is for something else?). If supposed to work, then it's
> currently broken and likely needs some more ifdefs. If not supposed to
> work, then the configure script should abort Xlib isn't present while
> configuring for XCB. I'm interested in fixing it either way, but I
> can't take the decision of what's supported :)
Do you have an opinion on why we should put a stronger emphasis on using xcb only? The reasons I can think of are
1) not loading xlib will save a little memory and load time
2) maybe it will perform better because xcb is so low-level that no functions have built-in wait-for-reply functionality; so if you write the code in a pipelined fashion as much as possible, it will spend less time waiting for replies
3) theoretically, new features are supposed to be added to xcb first
but the downsides I can think of are
1) xcb is such a low-level API that the code is tedious to write and maintain; it's no fun replacing convenient one-line function calls and having to think about all possible timings simultaneously: the usual question being, when is the latest that I can receive a reply to a particular request, so I can get as much else done as possible while waiting for it?
2) in fact, new features don't always get added to xcb first. When I wrote the XInput 2.2 support for touchscreens, xcb didn't have it. I guess I need to check again whether it does now. It should theoretically be easy for me to write the patch to add that to xcb, and I was thinking of doing that, but didn't get around to it yet. xcb is maintained by a small band of volunteers, so there's no reason to say for sure that new features get added there first; just that it was the intention.
So I'm not convinced the advantages are so strong to prioritize this very much.
Considering that there are some ifdefs, it makes sense to complete them so that it can build without xlib. Then maybe it makes sense to do that kind of build on CI to ensure that it continues to work. But it's also likely right now that there will be too many features missing to be practical anyhow. I thought the plan was to gradually rewrite the xlib dependent parts so that eventually we only need xcb, but that's tedious work so I'm not sure how long it will take to get rid of every last dependency.
More information about the Development