Thiago Macieira wrote:
> Because we're in 2014. Qt 4.0 was released in 2005 and the binary wasn't
> renamed. Software is supposed to work with the official version too and
> there are 9 years of history of us releasing "qmake".
>
> Therefore, that buildsystem needs to try qmake alone.
The point i
On Sunday 18 January 2015 23:13:30 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > This, Qt 3 software do "qmake". Qt 4 software do "qmake -v" to determine
> > which version it is: if they found Qt 3, they try "qmake-qt4". All of this
> > is already implemented and was in place before 2012.
>
> W
Lisandro Damián Nicanor Pérez Meyer wrote:
> On Sunday 18 January 2015 18:06:45 you wrote:
> [snip]
>> If I'm wrong then simply unmasking qdbus with qtchooser should be enough.
>> /usr/bin/qdbus should be provided by the default version (qt4's one in
>> our case) and we might even let qt5-qdbus de
Thiago Macieira wrote:
> This, Qt 3 software do "qmake". Qt 4 software do "qmake -v" to determine
> which version it is: if they found Qt 3, they try "qmake-qt4". All of this
> is already implemented and was in place before 2012.
Why would they need to try running anything? Just use qmake-qt4 if i
On Sunday 18 January 2015 22:17:24 Kevin Kofler wrote:
> Lisandro Damián Nicanor Pérez Meyer wrote:
> > No, there's also qdbus for instance. We in Debian had some problems when
> > users managed to get a qt4 program using qt5's qdbus by setting
> > qtchooser's default at qt5. The good side of this:
On Sunday 18 January 2015 22:48:45 Kevin Kofler wrote:
> Lisandro Damián Nicanor Pérez Meyer wrote:
> > With my distro-packager hat on I realize the best solution would have been
> > indeed using prefixed binaries
>
> Please make them suffixed (*-qt5), which is the established convention.
> (Debia
Lisandro Damián Nicanor Pérez Meyer wrote:
> With my distro-packager hat on I realize the best solution would have been
> indeed using prefixed binaries
Please make them suffixed (*-qt5), which is the established convention.
(Debian also used *-qt4 suffixes in the days where you shipped Qt 3 and
Konstantin Ritt wrote:
> There is no need for moc/rcc/uic to be suffixed. In fact, they are an
> internal build tools invoked by qmake and thus they should normally reside
> in libexec dir (or you may query qmake for its specific libexec dir path
> to invoke them manually) -- just like GCC's cc1 or
Thiago Macieira wrote:
> That said, back in 2012 when we were discussing the renaming, I made the
> argument that some of our binary executables are not "build tools" but are
> instead "user applications". Those should not be installed in a private
> libexec dir, but should be global in /usr/bin an
On Sunday 18 January 2015 18:06:45 you wrote:
[snip]
> If I'm wrong then simply unmasking qdbus with qtchooser should be enough.
> /usr/bin/qdbus should be provided by the default version (qt4's one in our
> case) and we might even let qt5-qdbus depend upon it's qt4 version, so
> packages depending
Lisandro Damián Nicanor Pérez Meyer wrote:
> No, there's also qdbus for instance. We in Debian had some problems when
> users managed to get a qt4 program using qt5's qdbus by setting
> qtchooser's default at qt5. The good side of this: it turned out to be a
> bug in qt5's qdbus which got fixed and
On Sunday 18 January 2015 18:06:45 you wrote:
[snip]
> And we can't even upstream those patches because on platforms other than
> Linux there is no qtchooser available
That would be available *and* enforced.
--
Simulations are not data. In God we trust, all the others must supply data.
Walter
On Sunday 18 January 2015 12:39:32 Thiago Macieira wrote:
> On Sunday 18 January 2015 15:02:21 Lisandro Damián Nicanor Pérez Meyer
wrote:
> > No, there's also qdbus for instance. We in Debian had some problems when
> > users managed to get a qt4 program using qt5's qdbus by setting
> > qtchooser'
On Sunday 18 January 2015 18:01:55 Pau Garcia i Quiles wrote:
> Hello,
>
> Mike Gonza worked on a wrapper of usb-serial-for-android and provided
> patches a while ago but they were not accepted because
> usb-serial-for-android is LGPLv2.1 only:
>
> https://codereview.qt-project.org/#/c/83480/
>
On Sunday 18 January 2015 06:56:28 Kevin Kofler wrote:
> The issues are:
> * conceptual: Choosing a Qt version ought to be:
> - the job of the software being built (i.e., its build system(*)), whose
> developer knows what version of Qt is needed, not the job of the user
> building the sof
On Sunday 18 January 2015 15:02:21 Lisandro Damián Nicanor Pérez Meyer wrote:
> No, there's also qdbus for instance. We in Debian had some problems when
> users managed to get a qt4 program using qt5's qdbus by setting
> qtchooser's default at qt5. The good side of this: it turned out to be a
> bu
I'll try to summarize my points of view on this issue as I have been
maintaining qtchooser almost since the beginning. Please bear in mind that
most of what I write here is with the experience gained during this time, had
I know it when the issue arose here in the mailing list I would have tried
2015-01-18 22:02 GMT+04:00 Lisandro Damián Nicanor Pérez <
perezme...@gmail.com>:
> On Sunday 18 January 2015 21:08:24 Konstantin Ritt wrote:
> [snip]
> > > for pretty much ANY build system out there.
> >
> > There is no need for moc/rcc/uic to be suffixed. In fact, they are an
> > internal buil
On Sunday 18 January 2015 21:08:24 Konstantin Ritt wrote:
[snip]
> > for pretty much ANY build system out there.
>
> There is no need for moc/rcc/uic to be suffixed. In fact, they are an
> internal build tools invoked by qmake and thus they should normally reside
> in libexec dir (or you may qu
2015-01-18 9:56 GMT+04:00 Kevin Kofler :
> Thiago Macieira wrote:
> > Please list them again, so we can address them. The one I can remember
> now
> > is the default config file for multilib, which is fixable by using
> > alternative. Multilib development is covering the sun with a sieve, so
> > p
Hello,
Mike Gonza worked on a wrapper of usb-serial-for-android and provided
patches a while ago but they were not accepted because
usb-serial-for-android is LGPLv2.1 only:
https://codereview.qt-project.org/#/c/83480/
https://codereview.qt-project.org/#/c/84338/
https://github.com/mik3y/usb-ser
I wrote:
> Actually, thinking of it, the right solution for this use case would be to
> just qtchooser-wrap qmake-qt5 and use:
> qmake-qt5
> qmake-qt5 -qt release
> qmake-qt5 -qt icc
> qmake-qt5 -qt clang
> qmake-qt5 -qt mips
> qmake-qt5 -qt static
> qmake-qt5 -qt 5.1
Or rather:
qmake-qt5
qmake-qt
Thiago Macieira wrote:
> Because it also works for those of us who have multiple Qt 5 builds. I can
> run:
> qmake -qt5
> qmake -qt5-release
> qmake -qt5-icc
> qmake -qt5-clang
> qmake -qt5-mips
> qmake -qt5-static
> qmake -qt5.1
Actually, thinking of it, the right solution for this use case would
when I add:
> Project: Qt
> Issue Type: Bug
> Summary: Ninja for qtwebengine out-of-source build not possible
> Affects Version/s: 5.5
> Component/s: Build System
> Description:
> When I do an out-of-source build, e.g. sources in 'qt5' and a
> '../qt5/configure' in a separate 'qt5-build' fol
24 matches
Mail list logo
