[Development] New proposal for the tool naming

[Konstantin Ritt]

Re on adjusting all the documentation to say "run qmake -qt5":
Let's count who will have Qt5 co-/installed:
1) Those who's DE is built against Qt5 and thus Qt5 is the default Qt
there; though, they may have Qt4 co-installed until all the qt-apps
in-use are ported to Qt5;
2) Those who are still on Qt4-based DE but want some qt-apps where Qt5
is installed as a dependency (most-probably they'll have the libraries
only);
3) Developers who need to build something against Qt5;
4) Ones who installs everything because they do not know what they are doing ;)

Only 1) and 3) are the ones who do need qmake. In both cases, it seems
to be safe to make Qt5 the default version that qmake is pointing to.
Moreover, shouldn't we mention Qt5 as a drop-in replacement for
Qt3/Qt4? So if the user does need to build something Qt based, let the
latest system-wide Qt version be the default one! I fhe doesn't, he
don't need qmake either.

Summary: to me, it seems like keep saying "run qmake" in the docs is
quite enough...

kind regards,
Konstantin


2012/10/23 Oswald Buddenhagen <oswald.buddenhagen at digia.com>:
> 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.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development