[Development] New proposal for the tool naming

Oswald Buddenhagen oswald.buddenhagen at digia.com
Tue Oct 23 15:04:10 CEST 2012


On Mon, Oct 22, 2012 at 01:38:56PM -0700, Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 20.52.49, Oswald Buddenhagen wrote:
> > > I can't fix what's already broken due to the Qt 3 and Qt 4 mess. I can
> > > only  fix going forward for Qt 5.
> > > 
> > 
> > i fail to see your argument here. what exactly is the reason why having
> > the "apps" and the "tools" in the same bindir would be bad?
> 
> 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.

> > > Symlinking the other tools is optional and should not be the default.
> > 
> > as i said three times already, lupdate is usefully user-invokable, and
> > the gui tools will be renamed by some distros anyway - so it is only
> > reasonable to isolate and include them into the aliasing magic - always,
> > to avoid fragmentation.
> 
> 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.

> 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.

> > > > i meant a "qt" tool without the "symlink trick". you totally don't want
> > > > to update all documentation to say "qt qmake", etc., and as a user i
> > > > positively don't want to type that.
> > >
> > > 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.

> 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.



More information about the Development mailing list