Having realized after some work that QtWebKit is now trying to achieve more or less the same as QtSerialPort ... how about about the udev resolver to QtCore now as a private stuff ... like qtlibudev_p.h or similar kind. Afterwards, QtWebKit could use core-private, so could QtSerialPort. We would also have to import it into our qt4support folder for sure...
This could then be refactored: https://codereview.qt-project.org/#change,69202 Just like this: https://codereview.qt-project.org/#change,69178 Cheers ... On Thu, Oct 24, 2013 at 11:03 PM, Laszlo Papp <lp...@kde.org> wrote: > Actually having thought a bit about this, and written the change more or > less, my personal opinion is that it would be better to get distribution > packages (via OBS or any other kind) correctly in the future... > > udev, and probably other libraries might not guarantee binary > compatibility for releases, and it may happen that they bump the version > frequently in which case it would hard to do cross-working software. > > Strictly speaking, dynamic library management even complicates the code > for everyone having to deal with udev, or some other similarly determined > libraries. > > If Qt can make sure in the future there are proper distribution packages > (at least for the common variants), this would not be such a big issue. I > understand it cannot happen any soon. I am personally fine with building > QtSerialPort for 5.2 without udev for the official installer. Archlinux, > and some other distribution users will get it right from the distribution > packagers after all. > > Well, this is my two cents. > > > On Thu, Oct 24, 2013 at 9:13 PM, Laszlo Papp <lp...@kde.org> wrote: > >> https://bugreports.qt-project.org/browse/QTBUG-34329 >> >> >> On Thu, Oct 24, 2013 at 4:36 PM, Knoll Lars <lars.kn...@digia.com> wrote: >> >>> Sounds like dlopen¹ing is the way to go. Sucky, but at least it¹ll work. >>> And according to the post below most things should be compatible between >>> udev0 and udev1. >>> >>> Cheers, >>> Lars >>> >>> On 24/10/13 16:28, "Thiago Macieira" <thiago.macie...@intel.com> wrote: >>> >>> >On quinta-feira, 24 de outubro de 2013 13:46:39, Koehne Kai wrote: >>> >> I just asked, it seems not to be possible: >>> >> >>> >> >>> http://www.marshut.com/yiqmk/can-apps-ship-their-own-copy-of-libudev.html >>> >> >>> >> >>> >> So we're back to either moving the libudev dependency to a plugin that >>> >> qtserialport tries to load (huh), we live with the fact that >>> >>qtserialport >>> >> won't work on some distributions, or we compile it unconditionally >>> >>without >>> >> libudev support. I don't mind either way ... >>> > >>> >Ok, thanks Kai >>> > >>> >That answers the part about shipping (static or dynamic). So the only >>> >option >>> >is dynamic loading (ugh) or skipping support entirely (also ugh). >>> > >>> >PS: None of the systemd developers were in my binary compatibility >>> >session >>> >yesterday here at LinuxCon. >>> > >>> >PPS: http://www.youtube.com/watch?v=jjRAKuis7T8 @ 16:55 >>> >"people have heard my complaints about the fact that the Linux desktop >>> is >>> >this >>> >morass of infighting and people who do bad things" >>> >"I do hope that the desktop people would just try to work together and >>> >work >>> >more on the technology" >>> >Linus started complaining about the problems on the userspace *because* >>> >of >>> >udev. See https://lkml.org/lkml/2012/10/2/303. >>> > >>> >-- >>> >Thiago Macieira - thiago.macieira (AT) intel.com >>> > Software Architect - Intel Open Source Technology Center >>> >_______________________________________________ >>> >Development mailing list >>> >Development@qt-project.org >>> >http://lists.qt-project.org/mailman/listinfo/development >>> >>> _______________________________________________ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >> >> >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
