> Distros would configure Qt with -prefix /usr -bindir /usr/lib/qt5/libexec etc.
Let's make it more flexible for those who will configure:
I'd rather -prefix /usr -bindir /usr/bin -libexecdir /usr/lib/qt5/libexec
since /usr/bin is still an important path where one would expect to
find some scripts, symlinks, etc.
(and of course, we should care about DESTDIR! :) )
> Wouldn't it be kind of weird though if the libQtCore.so symlink would live in
> say /usr/lib/qt5/lib but libQtCore.so.5.0.0 itself would be locacted in
> /usr/lib?
That's not so unusual. The last time I've installed mysql on my Linux
box, it was installing exactly like this.
> (and then add multi-arch to the mix :)
Also note that it could be /usr/lib{,64}, /usr/lib{32,}, or even
/usr/lib/{i686,x86_64}-unknown-linux-gnu. Whatever it is, I don't want
x64 libs and/or executables in my lib 32 dir or vice versa.
I'd expect /user/lib/qt5 and /usr/lib{,64}/qt5/lib for the libraries
and /usr/lib{,64}/qt5/{bin,libexec} for the platform specific/version
specific/"private" executables; the common parts are expected just in
/usr/share/qt5 (where collisions are ignored). Same applies to the
headers ( /usr/include/qt5 ) with one exception -- like Oswald
mentioned above, qconfig.h can be arch-specific and then I'd expect to
find it in /usr/lib{,64}/qt5/include .
This way we could reasonable keep out libraries not renamed.
That brings nothing new (and that's how I did co-installation of Qt3
and Qt4 on my BLFS box years ago).
Now, the more attractive thing - qmake!
The idea isn't new as well: let is be a script or a dumb small
executable that simply wraps the requested Qt's qmake. As for example:
> qmake -list-versions
*Qt-5.0.0-beta2-x32 -> /usr/lib/qt5/libexec/qmake
Qt-5.0.0-beta2-x64 -> /usr/lib64/qt5/libexec/qmake
Qt-5.0.0-daily-mingw32 -> /usr/local/opt/qt5/mingw32/bin/qmake
> qmake -use-version 5.0.0-daily-mingw32 (or -target mingw32)
> qmake -v
QMake version 3.0
Using Qt version 5.0.0 in /usr/local/opt/qt5/mingw32
> qmake -r project.pro && make
The switch could be done via the envvars, as for example.
Which installed version is the system-default one is up to the distro
maintainer. At the same time, this could work just ok for Qt6, for
developer's Qt and so on...
The only bitter pill for the packagers to swallow I see is to ensure
Qt4's qmake is renamed to something else or moved out from /usr/bin,
and to ensure that the newly-installed Qt gets registered into such a
qmake wrapper's database.
What I have missed?
Konstantin
2012/10/19 Laszlo Papp <lp...@kde.org>:
> On Fri, Oct 19, 2012 at 7:13 PM, Thiago Macieira
> <thiago.macie...@intel.com> wrote:
>> On sexta-feira, 19 de outubro de 2012 13.24.37, Simon Hausmann wrote:
>>> Regardless of the solution we find for Qt distro packages, it seems
>>> sensible that the Qt users can continue to find a /usr/bin/qmake program
>>> that corresponds to the most recent release of Qt. This provides
>>> consistency with Qt on other platforms as well as the handling of other
>>> command line programs such as python, gcc, ruby, etc. within the distros.
>>
>> I'm not sure I agree with this part. For one thing, you can bet that "qmake"
>> will *not* be Qt 5's for the next year or two, as people are still developing
>> Qt 4 applications.
>>
>> And like I said in another email, Qt 5's qmake is in an entirely different
>> category from gcc, ruby, etc.
>>
>> But I'm glad you brought python up!
>>
>> Fedora$ ls -l /bin/python /bin/python?
>> lrwxrwxrwx. 1 root root 7 Aug 6 15:23 /bin/python -> python2
>> lrwxrwxrwx. 1 root root 9 Aug 6 15:23 /bin/python2 -> python2.7
>> -rwxr-xr-x. 3 root root 12888 Jun 7 22:36 /bin/python3
>>
>> openSUSE$ ls -l /usr/bin/python /usr/bin/python?
>> lrwxrwxrwx 1 root root 9 Jul 8 03:03 /usr/bin/python -> python2.7
>> lrwxrwxrwx 1 root root 9 Jul 8 03:03 /usr/bin/python2 -> python2.7
>> lrwxrwxrwx 1 root root 9 Oct 19 10:38 /usr/bin/python3 -> python3.2
>>
>> Debian$ ls -l /usr/bin/python /usr/bin/python?
>> lrwxrwxrwx 1 root root 9 May 14 11:03 /usr/bin/python -> python2.6
>>
>> Ubuntu$
>> $ ls -l /usr/bin/python{,?}
>> lrwxrwxrwx 1 root root 9 Apr 17 2012 /usr/bin/python -> python2.7
>> lrwxrwxrwx 1 root root 9 Apr 17 2012 /usr/bin/python2 -> python2.7
>>
>> As you can see, they are not symlinks to /etc/alternatives/. Those are non-
>> configurable symlinks. So even if Python 3 were installed on those Ubuntu and
>> Debian, it still wouldn't have overwritten.
>>
>> If you want to take python as precedence, then we conclude "qmake" is for Qt
>> 4
>> and we need to find a new name for Qt 5.
>
> I have not personally been much fan of that schema... Thiago, I hope
> your next proposal will not be qmake5.0, qmake5.1 and the like based
> upon some "python precedence". :-)
>
> Laszlo
> _______________________________________________
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
