[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

Oswald Buddenhagen oswald.buddenhagen at theqtcompany.com
Tue Jan 20 10:57:43 CET 2015


On Tue, Jan 20, 2015 at 12:55:51AM -0300, Lisandro Damián Nicanor Pérez Meyer 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.
> 
on windows, the configure would just set the executable name without a
path, thus falling back to the "optimistic" case. that's perfectly fine,
because the user (or an installer or whatever) is expected to set up
PATH for the application anyway.

well, actually, this is nonsense. on windows, the application would just
ship its own qdbus, assistant, and whatever else.



More information about the Development mailing list