[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
Lisandro Damián Nicanor Pérez Meyer
perezmeyer at gmail.com
Tue Jan 20 04:55:51 CET 2015
On Monday 19 January 2015 19:07:29 Thiago Macieira wrote:
> On Monday 19 January 2015 15:18:41 Lisandro Damián Nicanor Pérez Meyer
wrote:
> > > Distributors are going a great job creating Qt packages. But not
> > > everyone
> > > is using their distro's Qt. In fact, looking at our customers I'd say
> > > that
> > > most of them have their own Qt install somewhere on their disk. Possible
> > > several installations even. Renamed binaries won't cope with that
> > > variety.
> > > Our product relies on a --with-qmake switch or PATH for selection.
> > > Version
> > > detections follows wherever named. Renamed binaries won't help. Or even
> > > make our life harder as it needs to be.
> >
> > If we are going to focus *just* on customers, yes, you might be right.
> >
> > But as far as I understand this is not just about customers, but also
> > about
> > users. And believe me, we have plenty of those
>
> I'm not sure I see the distinction between users and customers here.
>
> When you say "users", are you thinking of a person who builds a Qt-using
> software from a 3rdparty?
No, actually I'm meaning people who use software made with Qt in the special
case of "shadowed" executables, ie. executables that are called at runtime and
might differ between Qt major versions.
The truth we face is that we need to ship both major versions at the same
time. True, as Ossi wrote:
- We could just hope for the same-named tools to behave in the same way. But
would it be a bug if they start not doing so? Allow me an example. Due to the
fact that Qt4 existed before Qt5 we need to set the default Qt version to 4.
Now we know that right now Qt5's qdbus is backwards-compatible. Let's now
assume Qt5's qdbus adds a new feature. Now a Qt5 application calls qdbus
expecting this feature, but as Qt4 is the default it won't get it. We
maintainers get a fairly reasonable bug.
- We could ask upstream to call qmake and harcode the path at build time. This
solution sounded right at first, but then I *think* it won't work on windows.
And if this is the case we still need the app's developer to add an #ifdef or
something alike.
--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150120/9a7f73b1/attachment.sig>
More information about the Development
mailing list