Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)
On sexta-feira, 19 de outubro de 2012 19.32.05, Laszlo Papp wrote: > 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". Even though python does install python3.2 and python3.3, the name that people run is "python3", as seen in many scripts: #!/usr/bin/env python3 So I really don't care if we have qmake5.0, qmake5.1, qmake5.1.2-digia3, so long as there's a qmake5 that works and is the official way. Really, I don't care what qmake5 is and where it points to, so long as: a) it exists b) it works c) it's the official and documented way of creating Qt applications in Qt 5 Any other names are under the customer's taste. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)
> 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 :
> On Fri, Oct 19, 2012 at 7:13 PM, Thiago Macieira
> 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
Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)
On Fri, Oct 19, 2012 at 7:13 PM, Thiago Macieira
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
Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)
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.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)
On Fri, Oct 19, 2012 at 03:01:05PM +0200, Simon Hausmann wrote: > 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? > no, because libQtCore.so.5.0.0 would also live in /usr/lib/qt5/lib and the one in /usr/lib would be a symlink only. *all* FHS locations would be symlinks only. know the tool 'stow'? > (and then add multi-arch to the mix :) > just make it /usr/lib/i386-linux-gnu/qt5/lib. not sure how duplication of headers would be handled, but given that qconfig.h theoretically can be arch-specific, the whole set may need to be duplicated. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)
On Friday, October 19, 2012 02:24:09 PM Oswald Buddenhagen wrote: > On Fri, Oct 19, 2012 at 01:24:37PM +0200, Simon Hausmann wrote: > > (1) It seems that there is an agreement on the naming of the libraries and > > pkg-config files. > > not really. i'm not as strongly opposed to it as to renaming the tools, > but i think renaming the libraries is mostly counterproductive, too: > - the change is linux-only. on mac it simply cannot be done (in the > framework case) and on windows it is already this way. the latter is > rather ugly, as mentioned before. > - it is entirely unnecessary for deployment, as shared object versioning > perfectly supports co-installed major versions > - it is sort-of unnecessary for development, as -I & -L can be used to > specify which libraries to build against 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? (and then add multi-arch to the mix :) Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)
On Fri, Oct 19, 2012 at 01:24:37PM +0200, Simon Hausmann wrote: > (1) It seems that there is an agreement on the naming of the libraries and > pkg-config files. > not really. i'm not as strongly opposed to it as to renaming the tools, but i think renaming the libraries is mostly counterproductive, too: - the change is linux-only. on mac it simply cannot be done (in the framework case) and on windows it is already this way. the latter is rather ugly, as mentioned before. - it is entirely unnecessary for deployment, as shared object versioning perfectly supports co-installed major versions - it is sort-of unnecessary for development, as -I & -L can be used to specify which libraries to build against i'm considering renaming the pkg-config files, as they target specifically linux and are the official entry point for the last item above. it's far from decided, though. > In short: We find that there is no _need_ to rename the tools and that > we can solve the problem of co-installation using versioned > directories. > correct. i find andre's "implementation" more precise. your "proposal" is basically a summary of the status quo amongst linux distros. regards ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Alternative Proposal (was: Re: Summary of renaming changes)
On Thursday, October 18, 2012 08:30:03 AM Thiago Macieira wrote: [...] Tor Arne and I have been discussing this once more and we'd like to make an alternative proposal. But first let's try to summarize. (1) It seems that there is an agreement on the naming of the libraries and pkg-config files. (2) It also seems that there is an agreement that we don't have to rename the applications such as Qt Creator, Qt Designer, etc. - programs that are very much meant to be launched explicitly by the user via the menu. (3) This leaves us with the command line tools such as qmake, moc and uic where we have a conflict _only_ on Linux when they're installed by distributions in /usr/bin. On Mac OS X and Windows co-installation is an established concept for Qt users by containing each version in different directories and making a choice via the PATH environment variable. The same approach is used by users of Qt compiling from source on Linux as well. The only problem left is co-installation of Qt when it is supplied by the Linux distribution. 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. With this in mind, let's look at the possible options of namespacing the command line tools: (a) We can keep the names but contain them in a directory outside of /usr/bin, just like on Windows, Mac OS X and source builds. This would mean that /usr/bin/qmake is implemented as a symlink to for example /usr/lib/qt5/libexec/qmake. [See footnote [1] regarding the implementation of this solution] (b) We can pre-/postfix the binary names and leave them in their default location /usr/bin. This would mean that /usr/bin/qmake is implemented as a symlink to /usr/bin/qmake5. However for consistency this would mean that qmake would have to be renamed to qmake5 on the other platforms, too, where we don't have a problem to solve and the renaming just introduces unnecessary changes to existing workflows, as described by numerous people in this thread, such as having to change existing vcproj files or changes in Qt Creator to find the right qml viewer to launch. The first option however matches the other platforms and existing workflows and has no disadvantages compared to the pre-/postfixing of the binaries. In fact it has advantages, such as continuing to offer the ability to put the contained directory into your PATH, just like you do it for source builds and on the other platforms. In short: We find that there is no _need_ to rename the tools and that we can solve the problem of co-installation using versioned directories. Simon & Tor Arne [1] Implementation: Distros would configure Qt with -prefix /usr -bindir /usr/lib/qt5/libexec etc. This could also be implemented via a convenience ./configure -fhs-compliant parameter. We would then add an option to configure that ensures that at install time a symlink is created from /usr/bin/qmake to the binary in libexec. This allows you to call a specific version of qmake conveniently from /usr/bin if required. The only missing part then is the missing symlink of /usr/bin/qmake to the real qmake binary, which is a distribution specific mechanism, such as update- alternatives on Debian based distros. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
