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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development