[Development] New proposal for the tool naming

[Oswald Buddenhagen]

On Mon, Oct 22, 2012 at 11:19:17AM -0700, Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 19.23.23, Oswald Buddenhagen wrote:
> > > > only if you conveniently ignore my two (or three?) mails saying the
> > > > exact
> > > > opposite. the problem with renaming the libraries is the same as with
> > > > tools: project files not based on qmake need to be adjusted.
> > > 
> > > Indeed, but I contest that those changes are minor, expected and
> > > understandable. The vast majority of the users are probably using either
> > > qmake or cmake (99%?) and those are taken care of already.
> > 
> > the bottom line being "nobody cares". hey, wait, why change anything
> > at all then? ;)
> 
> Because of the portion of the 99% that *does* use qmake and needs to find it.
> 
yes. qmake will say /usr/lib/i386-linux-gnu/qt5/lib, where the
unversioned symlink can live witout conflicts.

> > anyway, the actual argument against doing it is that if we don't do the
> > invasive tool renaming, the library renaming is pointless (because it
> > doesn't help). and if we do something similar to the current proposal
> > ... the renaming is pointless (because the inc+lib paths can be found
> > with qmake).
> 
> Except if you want the .so files in /usr/lib co-installable with the Qt 4 ones. 
> Yeah, we could put them in /usr/lib/qt5/lib, but that sounds rather convoluted 
> to me. It also introduces multiarch issues, since then we need one qmake per 
> arch, instead of the solution we have now.
> 
you need a solution for that anyway, because both qconfig.pri and qmodule.pri
make qmake arch-specific.

> I want the Qt prefix to be /usr, not /usr/lib/qt5.
> 
well, i don't.

> > > How do they find the absolute path? The only answer is "qmake -query
> > > QT_INSTALL_BINS". Since my proposal keeps that compatibility, those
> > > buildsystems are not broken. This includes Creator's translation rules,
> > > for
> > > example.
> > > 
> > > And I contend that the Bucket A is already broken without user
> > > intervention. For Bucket A to work, the user must set the PATH to point
> > > to where the tools are. Either the user does this manually and will adapt
> > > anyway to a new installation, or the user has a script that she will
> > > again adapt. Since adaptation is necessary, adding the libexec path to
> > > PATH is no big deal.
> > so ... given that one of the cases is broken anyway and needs *some*
> > fix, what's the use of complicating the layout in an attempt to decouple
> > the case that needs no fixing anyway? :}
> 
> Exactly. That case that is broken needs attention and its solution is separate 
> from this discussion.
> 
> 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?

> > that asymmetry is ugly. that tool should be named just "qt" (or
> > similar) and *all* actual qt binaries should be reachable only via the
> > option or symlink.
> 
> That is acceptable too. I can call the tool anything and symlink qmake to it 
> (except on Windows where it will be an actual copy).
> 
there is historically little point in providing convenience "links" on
windows, because everyone uses PATH-based setups anyway. so the tool
would be only a qt registry manager (for creator). but anyway.

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

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

> > > > anyway, the bottom line is: this is an entirely separate tool/-set, and
> > > > qt should stay unmodified.
> > > 
> > > Yes and no: it's an entirely separate tool, except that it might need to
> > > be
> > > bootstrapped. That would require it live in qtbase.git.
> > 
> > we don't actually need bootstrapping, only static linking.
> 
> True, but you're splitting hairs. The "static QtCore" library in the regular 
> build is called "libbootstrap.a".
> 
the difference is that your interpretation forces the tool into qtbase
(unless i make the bootstrap library available separately, which is well
an option), while my interpretation makes only a regular static build a
precondition of building the tool independently.

> > anyway, using qt may be advisable if we use a config file based registry.
> > that's one of the reasons why i suggested that maybe we shouldn't.
> > but then, ini file and registry access (if even wanted) are pretty
> > trivial to write in plain c (look at kdm's inifile.c ...).
> 
> I was planning on simple multiple-file reading. One file per Qt version it 
> knows. It's a lot simpler and more package-friendly.
> 
that makes sense for the system-provided qts (though as i wrote before,
this can be deduced based on filesystem policy without any additional
information). for user-defined qt versions you need to write something
to ~/.config/QtProject/qtversions* anyway - whether it's a single file
or multiple doesn't make *that* much of a difference.