On terça-feira, 23 de outubro de 2012 15.04.10, Oswald Buddenhagen wrote: > > Because qdbus should be in /usr/bin but the version- and arch-specific > > qmake should be somewhere in /usr/lib*/qt5. > > ok, i can buy that as such. > however, i totally see no point in us doing this upstream, and why qmake > (or even qlibraryinfo) should be in any way concerned with it.
We've been over this: because I'd rather do this right and once and for all.
Who are the best people to make sure that all tools continue to work under
those conditions? Upstream is.
The alternative is that we're responsible for the configuration that
dowsntreams use as well as the patches they may have had to apply to make it
work.
> > So we provide symlinks for a few of the tools in addition to qmake, but I
> > don't see why moc should be in $PATH. The number of people who actually
> > run it manually must be countable in one hand.
>
> i'm pretty sure that *some* build systems rely on moc being in the path.
> one could argue that they are broken - but then, it exactly fits the
> /usr/bin philosophy, so it's hard to blame them.
We've been over this, again. If they rely on $PATH without user intervention,
they are already broken, as /usr/bin/moc might be Qt 4's.
But I'm not against wrapping the tools.
> > On the other hand (the one not counting people), applications like qdbus
> > or
> > xmlpatterns make no sense to have in duplication.
>
> actually, xmlpatterns (just like lupdate) can be usefully called both
> manually and from build scripts.
True, but unlike lupdate, the functionality, purpose and output do not change
from version to version. The Qt 5 xmlpatterns cleanly replaces the old Qt 4
one. There's no need to duplicate.
> > > > I do want to update all the documentation to say "qmake -qt5".
> > >
> > > well, i'm pretty sure you didn't really think about that. otherwise
> > > i'd have to declare you insane. ("all the documentation" is a tad more
> > > than a few qdoc files).
> >
> > Yes, I really meant it. We have to start somewhere.
>
> it's official then: you are insane. :D
> anyway, i would think that both we and our users have better things to
> do ... and as you may have noticed, rewriting the book (in this case
> kinda literally) is typically met with skepticism, to put it mildly.
Correcting 15 years of doing installations takes time and usually meets with
resistance.
> > I would prefer to have the tool inside qtbase, [...]
> >
> > since this tool is the entry point for building Qt5-based applications, it
> > must either come with Qt or not depend upon it.
>
> actually, not at all.
> as we established, this is an entirely optional, external add-on. it's
> not necessary for building qt at all - the environment in which qt is
> built can be very well self-contained, as it has always been.
> i strongly prefer to have it outside qt itself.
If we add the "-qt5" option to the traditional qmake, then it can be
considered optional.
I still prefer to develop it inside qtbase.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
