Re: [Development] Summary of renaming changes
On 19.10.2012 19:26, Sune Vuorela wrote: no. it would be if you compiled Qt yourself or if you downloaded the built editions from digia, write qmake to build things. if you gotten from your linux distribution write probably qmake5, Developers tend to be computer savvy people, they should be able to figure out a path to a binary on their system. Windows devs certainly can... I hope you are not implying Linux devs are more stupid than windows devs;-) If a distribution feels that it needs to provide a default Qt for newbie developers to use, then it can always install a symlink to /usr/lib/ia64-linux-gnu/qt5/bin/qmake into /usr/bin and be done with that. Somebody just wanting to get his feet wet with Qt programming will not care too deeply about the exact Qt version anyway (most likely not even whether it is Qt 4 or 5). but maybe the distro chose some other naming scheme so it could also be qmake-qt5 or /usr/lib/ia64-linux-gnu/qt5/bin/qmake Distributions will always rename/move around/leave out binaries. That is a distribution's core competence;-) Seriously: Distros have widely differing setups that can influence packaging. Some support multiarch installations, some need to press their distro into a distribution medium of a certain size, others do not. Some have special licensing needs, some will use virtualization/containers to provide better security, etc. There is just no way upstream can not address all this. So let's make sure Qt installs cleanly on Linux systems in an as self-contained way as possible. Ideally distro-provided Qts should feel similar to self-compiled Qts (or those from an SDK) and similar to Qts on other systems like windows and mac. To me that seems to be to install the binaries into a place outside of $PATH. Maybe we could provide recommendations for symlinks to be put into $PATH, but that is all we should do IMHO. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. USt-IdNr: DE xxx xxx xxx Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On 21/10/2012 18:42, Knoll Lars wrote: Please read Thiago's latest proposal (see thread 'New proposal for tools naming'). It proposes something very similar to what you are asking for here. Yeah seen the different thread too late. :-/ The latest proposal looks very good to me! Cheers, Jörg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
Hi Thiago, This *is* the problem of Linux distributions. FHS doesn't cover this problem properly and this is the point where it should be fixed. You're making life harder for every platform - not only Linux - by fixing their problem. You may argue that case, but they'll argue back that this solution has worked quite well for almost all packages for over a decade. OK I'm accepting reality and that what worked for so long is assumed to be the right way and won't be changed. I'm even going so far to admit that we might have to act. :) What still is questionable is the way of doing that. What we have is a naming clash between two installed versions. IMHO the least elegant way is to rename all relevant files in one of these versions. For these kind of conflicts there are namespaces. Every file system that's relevant to our case has a namespace feature: subdirectories. Apparently this feature is out for /usr/bin. Even /usr/bin/X11 is a symlink to /usr/bin on Debian wheezy that I'm using here. But hey, here's an interesting example: llvm. Binaries are in /usr/lib/llvm-3.0/bin and /usr/bin contains symlinks to its contents. These symlinks end with llvm's version number. Same pattern applies to the 2.7 llvm version that's installed here. Why can't we have something alike for Qt? If your fear is that different distros use different link names then please take these things into consideration: - Our target audience is software developers, they'll be able to enter qmake, press TAB twice and choose the right link. (Well if the version number is appended and not prepended, anyways.) - We can publish a recommendation for packaging Qt. - Some distros might want to use a different naming scheme. If all of this is totally impossible then please add a configure option that's off by default, like -qtlibinfix. Cheers, Jörg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
Hi Joerg, On Oct 21, 2012, at 5:48 PM, Bornemann Joerg joerg.bornem...@digia.com wrote: Hi Thiago, This *is* the problem of Linux distributions. FHS doesn't cover this problem properly and this is the point where it should be fixed. You're making life harder for every platform - not only Linux - by fixing their problem. You may argue that case, but they'll argue back that this solution has worked quite well for almost all packages for over a decade. OK I'm accepting reality and that what worked for so long is assumed to be the right way and won't be changed. I'm even going so far to admit that we might have to act. :) What still is questionable is the way of doing that. What we have is a naming clash between two installed versions. IMHO the least elegant way is to rename all relevant files in one of these versions. For these kind of conflicts there are namespaces. Every file system that's relevant to our case has a namespace feature: subdirectories. Apparently this feature is out for /usr/bin. Even /usr/bin/X11 is a symlink to /usr/bin on Debian wheezy that I'm using here. But hey, here's an interesting example: llvm. Binaries are in /usr/lib/llvm-3.0/bin and /usr/bin contains symlinks to its contents. These symlinks end with llvm's version number. Same pattern applies to the 2.7 llvm version that's installed here. Why can't we have something alike for Qt? If your fear is that different distros use different link names then please take these things into consideration: - Our target audience is software developers, they'll be able to enter qmake, press TAB twice and choose the right link. (Well if the version number is appended and not prepended, anyways.) - We can publish a recommendation for packaging Qt. - Some distros might want to use a different naming scheme. If all of this is totally impossible then please add a configure option that's off by default, like -qtlibinfix. Please read Thiago's latest proposal (see thread 'New proposal for tools naming'). It proposes something very similar to what you are asking for here. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On sábado, 20 de outubro de 2012 09.53.24, Alberto Mardegan wrote:
As you mentioned in another message, it would be great if these paths
were discoverable, either with a qt5-config tool or (better, IMHO) with
a qt5.pc pkg-config file defining these variables, so that one could do:
$ pkg-config --variable=QT_INSTALL_BINS qt5
/usr/lib/qt5/bin
They're in Qt5Core.pc already:
$ cat lib/pkgconfig/Qt5Core.pc
prefix=/home/thiago/obj/qt/qt5/qtbase
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include/QtCore
qt_config=lex yacc warn_on debug exceptions depend_includepath wayland-scanner
qt warn_on link_prl incremental gdb_dwarf_index qpa no_mocdepend debug
qt_no_framework linux unix posix gcc qpa largefile precompile_header sse2 sse3
ssse3 sse4_1 sse4_2 avx avx2 pcre create_prl link_prl use_libmysqlclient_r
no_private_qt_headers_warning QTDIR_build exceptions shared qt_install_module
qt_install_headers qt warn_on depend_includepath qmake_cache target_qt
qt_install_module_docs create_cmake hide_symbols bsymbolic_functions c++11
create_pc create_libtool explicitlib have_target thread dll shared
moc_location=${prefix}/bin/moc5
rcc_location=${prefix}/bin/rcc5
lupdate_location=${prefix}/bin/lupdate
lrelease_location=${prefix}/bin/lrelease
Name: Qt5core
Description: Qt Core module
Version: 5.0.0
Libs: -L${libdir} -lQt5Core
Libs.private: -lpthread -lz -licui18n -licuuc -lm -ldl -pthread -lgthread-2.0
-lrt -lglib-2.0
Cflags: -I/home/thiago/obj/qt/qt5/qtbase/include -I${includedir}
--
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] Summary of renaming changes
-Original Message- From: development-bounces+maurice.kalinowski=digia@qt-project.org [mailto:development-bounces+maurice.kalinowski=digia@qt-project.org] On Behalf Of Thiago Macieira Sent: Freitag, 19. Oktober 2012 02:38 To: development@qt-project.org Subject: Re: [Development] Summary of renaming changes On sexta-feira, 19 de outubro de 2012 10.17.39, Lincoln Ramsay wrote: On 19/10/12 01:30, Thiago Macieira wrote: After all of my patches are integrated, here are the changes that will happen: - bin: The following tools have been renamed: So... You just don't care about the calls from myself and others to leave the names alone instead install newly-named (aliased) things into common directories (ie. /usr/bin) as is standard practice for other things that get co-installed? I'm not ignoring. I was just summarising the effort I've done so far. I'm posting it so we can review it and correct further, if needed. eg. /usr/bin -- something special has to be done here, (eg. qmake-qt5 or qmake as a symlink to a specific Qt install) /usr/lib/qt5/bin -- binaries go here with their NORMAL names Thanks, but I don't think that solves many problems. That extra path would exist only for people like you or I who are used to them. I don't see further use for them. Here's why: External tooling will need to deal with the new names. For example, a buildsystem needs to search for qmake5 or qmake-qt5. And it needs to find qmake so that it can query where the other binaries are located, as they could be in: /usr/lib/qt5/bin /usr/lib64/qt5/bin /usr/lib/i386-linux-gnu/qt5/bin /usr/local/lib/qt5/bin /home/thiago/obj/qt/qt5/qtbase/lib/qt5/bin and so forth The tool cannot depend on the legacy path being on $PATH or that, if it is on $PATH, that the Qt 5 path comes before the Qt 4 one. Besides, we as helpgivers cannot depend on that either when giving advice: we need to tell people to run qmake5. What's more, this creates more work for us (well, for me, since I'm the one doing this). Adding symlinks in either direction is very hard, especially since they don't work on Windows. The tool would need to be copied instead[1]. On Windows there is no global qmake or such to call and distinguish between versions. Each Qt version will have to live in its own package, either made by the binary distribution or self-compiled. Hence that argument is obsolete. So you are creating distribution scripts which then point to the currently used Qt version for qmake? If not, who is creating those for the other libraries/tools, which follow a similar attempt of having a simlink in /usr/bin or /usr/local/bin pointing to libexec. Has anyone talked to those package managers how they see it? Maurice I did propose that we move all binaries except qmake and the end-user applications to a libexec dir, which is basically what that dir of yours is. It didn't happen because, as I was starting this effort, I was convinced to go for the option of renaming everything instead: moc, uic, rcc, etc. are well- defined tools with well-defined interfaces, manuals, etc.. They are not internal helpers. [1] we already copy the .dll files because of that problem and the DLLs are much larger, so copying the executables is no big deal. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 06.07.34, Kalinowski Maurice wrote: On Windows there is no global qmake or such to call and distinguish between versions. Each Qt version will have to live in its own package, either made by the binary distribution or self-compiled. Hence that argument is obsolete. For Windows, that's correct. So you are creating distribution scripts which then point to the currently used Qt version for qmake? If not, who is creating those for the other libraries/tools, which follow a similar attempt of having a simlink in /usr/bin or /usr/local/bin pointing to libexec. Has anyone talked to those package managers how they see it? No, we're not creating scripts. As I replied to Lorn, I don't see the value in having qmake duplicated in $bindir and $libexecdir. Since $bindir/qmake is already taken, if we put something in $bindir, it needs to be called something else. The only other option is to not install anything in $bindir. If we choose that, however, how will users find qmake in the first place? So we have $bindir/qmake5 and we update all the documentation to say qmake5. What's the use of $libexecdir/qmake now? In my plan, qmake will never be for Qt 5. Whether it's for Qt 3 or for Qt 4, it's undefined. That mess is already present and we can't fix it anymore. -- 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] Summary of renaming changes
On Oct 19, 2012, at 9:31 AM, Knoll Lars lars.kn...@digia.com wrote: Hi, looks like there's quite some discussion about Thiago's proposal. Let's see if we can get at least agreement on most of the changes and then focus on the parts that are controversial. To me this looks like a case where there clearly won't be a consensus, which means we're going to need a Chief Maintainer decision at some point. I hope we can all respect what ever that will be, and then move on. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
looks like there's quite some discussion about Thiago's proposal. Let's see if we can get at least agreement on most of the changes and then focus on the parts that are controversial. Going through the list below, most of the changes will not affect anybody in a big way. On Oct 18, 2012, at 5:30 PM, Thiago Macieira thiago.macie...@intel.com wrote: After all of my patches are integrated, here are the changes that will happen: - bin: The following tools have been renamed: qmake - qmake5 This one is visible to the developer. This is the one that's going to be hard for people to swallow the most especially on Windows as there the whole setup is straightforward as you just ensure you have the one version of Qt in your path and thus it will point to the right one. I've been doing this for a long time as do a number of people I have communicated with in the past even within the Qt 4.x range because one version of qmake is strictly speaking not compatible with the other even from 4.8.1 to 4.8.2 because it has hard-coded paths in it. So you could still end up picking up the wrong version anyway and subsequently end up compiling and linking against the wrong version of Qt but generally at that level it is not a big problem at least. Is there no way we could compromise on this? For instance by adding a symlink or something like that so that if someone types qmake it will invoke qmake5, that way if the distributors don't want that they can just remove it and then everyone is happy, the docs would refer to qmake5 and there is a solution there to help people transition over. Granted I know that people could just add this themselves, but I get the feeling that I will be hearing a lot about this otherwise. [snip] lconvert- lconvert5 lrelease- lrelease5 lupdate - lupdate5 These tools are in-between, as they IMO get called both by build systems as well as by developers directly. But if they are not compatible with Qt 4, we can't really have the same name unfortunately. For these I have the same problem as I do with qmake because they are invoked by the user directly too and thus the same suggestion about having a symlink stands in this case for me too. [snip] Maybe we should open this up for more feedback on a blog post perhaps? A lot of the people would be using it aren't necessarily going to see the change here and therefore they may have some good comments on it. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
Another thing that comes to my mind, that will break when renaming tools,
instead of installing links in paths like /usr/bin and keeping the the tools
unrenamed in specific version directories:
At the moment one can define an external tool in Qt Creator.
Configuration of these external tools is in Environment External Tools, you
can define any executable to run there with arguments etc, and a menu item for
the tool will be shown in Tools External.
E.g. we ship by default with an external tool definition for running lupdate
and lrelease, and the executable we run is defined as:
%{CurrentProject:QT_INSTALL_BINS}/lrelease
Qt Creator resolves that variable in there by taking the current project,
taking the current Qt version setting for that project, and asking that Qt
version for qmake -query QT_INSTALL_BINS.
At the moment that should work for Qt4 and Qt5.
If you rename lrelease to lrelease5 (or any other tool that we ship), this is
no longer possible and gets pretty fancy.
++ Eike
On 19 Oct 2012, at 01:10, Thiago Macieira thiago.macie...@intel.com wrote:
On sexta-feira, 19 de outubro de 2012 01.03.29, André Pönitz wrote:
On Thu, Oct 18, 2012 at 08:30:03AM -0700, Thiago Macieira wrote:
lconvert- lconvert5
lrelease- lrelease5
lupdate - lupdate5
Sorry, I don't get the joke.
Because it was no joke. It's serious.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
--
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On 19 Oct 2012, at 02:37, Thiago Macieira thiago.macie...@intel.com wrote: On sexta-feira, 19 de outubro de 2012 10.17.39, Lincoln Ramsay wrote: On 19/10/12 01:30, Thiago Macieira wrote: After all of my patches are integrated, here are the changes that will happen: - bin: The following tools have been renamed: So... You just don't care about the calls from myself and others to leave the names alone instead install newly-named (aliased) things into common directories (ie. /usr/bin) as is standard practice for other things that get co-installed? I'm not ignoring. I was just summarising the effort I've done so far. I'm posting it so we can review it and correct further, if needed. eg. /usr/bin -- something special has to be done here, (eg. qmake-qt5 or qmake as a symlink to a specific Qt install) /usr/lib/qt5/bin -- binaries go here with their NORMAL names Thanks, but I don't think that solves many problems. That extra path would exist only for people like you or I who are used to them. I don't see further use for them. Here's why: External tooling will need to deal with the new names. I don't see why. It's possible to ask qmake for the path where the other binaries, headers, examples, and a lot of other stuff are supposed to be: qmake -query. If we set the standards for distributions to have also e.g. /usr/lib/qt5/bin/qmake in addition to a symbolic link from /usr/bin/qmake to the current setting, a script can take qmake from the PATH (which can be set to whatever), and ask it where the other things are. For example, a buildsystem needs to search for qmake5 or qmake-qt5. And it needs to find qmake so that it can query where the other binaries are located, as they could be in: /usr/lib/qt5/bin /usr/lib64/qt5/bin /usr/lib/i386-linux-gnu/qt5/bin /usr/local/lib/qt5/bin /home/thiago/obj/qt/qt5/qtbase/lib/qt5/bin and so forth The tool cannot depend on the legacy path being on $PATH or that, if it is on $PATH, that the Qt 5 path comes before the Qt 4 one. Besides, we as helpgivers cannot depend on that either when giving advice: we need to tell people to run qmake5. What's more, this creates more work for us (well, for me, since I'm the one doing this). Adding symlinks in either direction is very hard, especially since they don't work on Windows. The tool would need to be copied instead[1]. I did propose that we move all binaries except qmake Why leave qmake out of the equation? and the end-user applications to a libexec dir, which is basically what that dir of yours is. It didn't happen because, as I was starting this effort, I was convinced to go for the option of renaming everything instead: moc, uic, rcc, etc. are well- defined tools with well-defined interfaces, manuals, etc.. They are not internal helpers. [1] we already copy the .dll files because of that problem and the DLLs are much larger, so copying the executables is no big deal. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
May I ask some stupid question: how many different qmake-s you're need in your $PATH ?! Maybe it's only me? - on Windows I do have a directory per Qt build, on Linux I do have symlink /user/bin/qmake - /usr/opt/Qt/4.8/bin/qmake. And I never have a feeling I need few more qmake-s around! 2012/10/19 Ziller Eike eike.zil...@digia.com: It's possible to ask qmake for the path where the other binaries, headers, examples, and a lot of other stuff are supposed to be: qmake -query. If we set the standards for distributions to have also e.g. /usr/lib/qt5/bin/qmake in addition to a symbolic link from /usr/bin/qmake to the current setting, a script can take qmake from the PATH (which can be set to whatever), and ask it where the other things are. That's almost the same I've told about at IRC today :) Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
Thiago Macieira: On sexta-feira, 19 de outubro de 2012 06.07.34, Kalinowski Maurice wrote: On Windows there is no global qmake or such to call and distinguish between versions. Each Qt version will have to live in its own package, either made by the binary distribution or self-compiled. Hence that argument is obsolete. For Windows, that's correct. So you are creating distribution scripts which then point to the currently used Qt version for qmake? If not, who is creating those for the other libraries/tools, which follow a similar attempt of having a simlink in /usr/bin or /usr/local/bin pointing to libexec. Has anyone talked to those package managers how they see it? No, we're not creating scripts. As I replied to Lorn, I don't see the value in having qmake duplicated in $bindir and $libexecdir. Since $bindir/qmake is already taken, if we put something in $bindir, it needs to be called something else. The only other option is to not install anything in $bindir. If we choose that, however, how will users find qmake in the first place? So we have $bindir/qmake5 and we update all the documentation to say qmake5. What's the use of $libexecdir/qmake now? In my plan, qmake will never be for Qt 5. Whether it's for Qt 3 or for Qt 4, it's undefined. That mess is already present and we can't fix it anymore. I started -2'ing the changes, based on the outcome of a cost/benefit analysis: - The problem only exists on Linux * There are existing, working solutions to the problem there * There are skilled people (distro packagers) there perfectly capable of handling the problem * The majority of Qt users is not affected at all. - The solution is invasive. * Some of the follow-up changes are only triggered by the renaming E.g. the need to co-install lupdate does not exist yet, but is _introduced_ by the qmake changes. * It affects any user project setup involving moc, uic, etc custom buildstep, like the ones _all_ Qt using Visual Studio projects have, therefore eliminating the possibilty of having a code base running on both Qt 4 and Qt 5, and even hampering a direct Qt 4 - Qt 5 port. * Documentation needs to be adjusted. * Existing third party documentation of Qt in use, howto's, tutorials, in the *net lose value, because it will be not accurate anymore. This is a completely unreasonable trade-off. Andre' Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
Sorvig Morten wrote: Knoll Lars lars.kn...@digia.com wrote: Hi, looks like there's quite some discussion about Thiago's proposal. Let's see if we can get at least agreement on most of the changes and then focus on the parts that are controversial. To me this looks like a case where there clearly won't be a consensus, which means we're going to need a Chief Maintainer decision at some point. I hope we can all respect what ever that will be, and then move on. The problem is only solved by a decision if the decision is stay put. In the other case, someone has to cleanup the fallout. Neither tooling nor user projects will magically adjust just because there was a Word. Andre' PS: I honestly start wondering how a change with such an impact can be seriously considered _at all_ that late in the process. Trivial additions have been rejected for months because we are in feature freeze and now _that_. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On 2012-10-19, Alberto Mardegan ma...@users.sourceforge.net wrote: 3) Provide a script to switch, per user and maybe even per $PWD, what version of Qt /usr/bin/qmake should generate the makefiles for. I have, as a distributor, frequently gotten 'hate' in #qt for providing switchable qmakes. And from a 'user support' PoV, having to write depending on what you have set as your default you can maybe write qmake, maybe you need to oither switch the default to qt5 or alternatively write qmake5 to build things is a much longer sentence than write qmake5 to build things. The advantage of doing it upstream, rather than having me to do it, kevin to do it, will to do it, jonathan to do it, ... is that - the implementation is the same - the result is the same - you do not have to consider what distribution teh user is on when trying to help in #qt, on interest@ or in forums. just write 'use qmake5 /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On Thursday, 2012-10-18, Shawn Rutledge wrote: I have another idea in mind for qmlviewer... You can configure your system so that double-clicking a .qml file opens it in qmlviewer. This would be a nice use case to suggest/support, because it's silly to be required to write a boilerplate C++ launcher for every little app or utility that you write in QML. As you have mentioned yourself later on, a .qml extension alone is not sufficient information to determine its runtime requirements. There is the difference between QtQuick1 and QtQuick2, at least needing a different view. Then there is BB10 Cascades, needing a very different application instance, KDE Plasma .qml might also have their own requirements. The explicit split in Qt5 between QML and QtQuick2 makes it even more likely that we will see other usages of the QML engine to provide declarative input for processing problems (IIRC there is a QML based cmake frontend prototype). Cheers, Kevin -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Kevin Krammer | kevin.kram...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On Fri, Oct 19, 2012 at 11:00:04AM +, Sune Vuorela wrote: On 2012-10-19, Alberto Mardegan ma...@users.sourceforge.net wrote: 3) Provide a script to switch, per user and maybe even per $PWD, what version of Qt /usr/bin/qmake should generate the makefiles for. I have, as a distributor, frequently gotten 'hate' in #qt for providing switchable qmakes. using (debian style) altenatives for that is pretty stupid. using a menu function which manipulates PATH in the current shell is exactly the right thing to do. that's the ominious qset some trolls have been talking about. The advantage of doing it upstream, rather than having me to do it, kevin to do it, will to do it, jonathan to do it, ... is that - the implementation is the same - the result is the same - you do not have to consider what distribution teh user is on when trying to help in #qt, on interest@ or in forums. just write 'use qmake5 as i've already written about three times, this is an argument for you guys finally agreeing on something and actually sticking to it, not upstream forcing this change on *all* users. regards (slightly annoyed ones by now) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
as i've already written about three times, this is an argument for you guys finally agreeing on something and actually sticking to it, not upstream forcing this change on *all* users. I fully agree. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
Sune Vuorela [nos...@vuorela.dk] I have, as a distributor, frequently gotten 'hate' in #qt for providing switchable qmakes. And from a 'user support' PoV, having to write depending on what you have set as your default you can maybe write qmake, maybe you need to oither switch the default to qt5 or alternatively write qmake5 to build things is a much longer sentence than write qmake5 to build things. The advantage of doing it upstream, rather than having me to do it, kevin to do it, will to do it, jonathan to do it, ... is that - the implementation is the same - the result is the same - you do not have to consider what distribution teh user is on when trying to help in #qt, on interest@ or in forums. just write 'use qmake5 That's achievable by a few lines of text: Linux distributors are strongly advised to install all Qt 5 related executables (qmake, uic, rcc, ...) with unmodified names to a directory that is not in $PATH and set up symlinks 'qmake5' etc that are in $PATH. Linux distributors are strongly advised to install all Qt 4 related executables (qmake, uic, rcc, ...) with unmodified names to a _different_ directory that is not in $PATH and set up symlinks 'qmake4' etc that are in $PATH. If Linux distributors feel strong about it, they may use their distributions native system to handle alternatives to set up 'qmake' etc links in the path to point to the qmake binary in either the Qt 4 or the Qt 5 binaries directory, [Suggesting to modify PATH is probably the saner choice, I don't really care about this part] User support could then be: write qmake5 to build Qt 5 things Users/Admins could then use the distribution's defaults system to switch the system Qt version, they can also override the system setup by modifying their local PATH settings, per-shell even. None of these operations are unusual, or technically challenging, or cumbersome, and it does not require, or even only benefit, from the proposed renaming of the binaries. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On 19 October 2012 12:29, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: On Fri, Oct 19, 2012 at 11:00:04AM +, Sune Vuorela wrote: On 2012-10-19, Alberto Mardegan ma...@users.sourceforge.net wrote: 3) Provide a script to switch, per user and maybe even per $PWD, what version of Qt /usr/bin/qmake should generate the makefiles for. I have, as a distributor, frequently gotten 'hate' in #qt for providing switchable qmakes. using (debian style) altenatives for that is pretty stupid. using a menu function which manipulates PATH in the current shell is exactly the right thing to do. that's the ominious qset some trolls have been talking about. There is also 'modules' (http://modules.sourceforge.net/) which is used at my University to achieve a similar thing. -- Matt Williams http://milliams.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 11.54.36, Joerg Bornemann wrote: On 18/10/2012 19:09, Thiago Macieira wrote: Let me be very clear: the distributions aren't fixing the distribution's problem. They'd be fixing *ours*. Putting every binary into one directory excludes installing different versions of one binary. Obviously the coinstallation problem is unsolved for Linux distributions. Everyone is forced to do nasty workarounds where this could be solved in a proper way by agreeing on a standard. Different versions of one binary but that retain backwards compatibility and purpose is not an issue. Those are rare cases anyway and, sure, tricks are often needed. One case people keep bringing up is GCC. So let's talk about GCC. When I last upgraded GCC from 4.6 to 4.7, it still compiled my programs. Where it didn't, it was usually broken code anyway. GCC developers reserve the right to fix bugs with their compliance with the C++ standard, just like we do reserve the right to fix bugs and change behaviour so long as we're still following our documentation. So when I last upgraded GCC, it simply replaced the old one. gcc used to be 4.6, now it is 4.7. The purpose is still the same: compile C and C++ programs. The same can be said of, for example, CMake. Whenever there's an upgrade, from 2.6 to 2.8, to 2.8.8, etc., it still performs the same functions. It still parses the same .txt files and loads the same scripts from /usr/share/cmake. Their developers are actually quite careful about changing even small behaviour changes, which are triggered only by setting options (the policies). But that can't be said of qmake. Upgrading qmake from Qt 4's version to Qt 5's changes it completely. It does not parse the same .prf files, they're not even in the same location! It does not serve the same purpose: that of compiling an application for Qt 4. The qmake that comes with Qt 5 is serving an entirely different *purpose* than the one that came with Qt 3 or Qt 4. That's why it needs to be allowed to co- exist with those others. This *is* the problem of Linux distributions. FHS doesn't cover this problem properly and this is the point where it should be fixed. You're making life harder for every platform - not only Linux - by fixing their problem. You may argue that case, but they'll argue back that this solution has worked quite well for almost all packages for over a decade. But I think that discussion is irrelevant and moot. The distributions will not change. If we fail to apply the fixes to our build, they will patch Qt and they've said as much on this mailing list. The end result of that is that they change *our* product, which means our documentation no longer applies to people who develop from packages, the help we give in #qt or other forums isn't entirely accurate. What's more, they may introduce subtle bugs that may take a long time to be discovered. When tools like lrelease and lupdate fail to work, who will the users blame? Distributions or us? -- 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] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 07.09.40, Koehne Kai wrote: So, _if_ we already rename half of the tools I don't see why qmlplugindump + qmlviewer should be the exception. Same goes for qmlviewer. Designer is a bit different since I guess 90% of the people just use it with stock component sets ... Ok, I haven't (un)done the change yet, so I'm holding back on it now. -- 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] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 07.45.15, Koehne Kai wrote: I guess the reason is that there's already a qmlviewer - the Qt 4 one. If we also go with qmlscene -qml2viewer, we'd have qmlviewer - qt4 qml1viewer - Qt 5, Qt Quick 1 qml2viewer - Qt 5, Qt Quick 2 Not exactly intuitive, is it ? Also, what happens if we release a Qt 6 with a qml 2 compatibility viewer? Thinking about it, I'd rather keep the qmlviewer, qmlscene names, and go for qmlviewer - qt 4 qmlviewer5 - qt 5 , qtquick 1 qmlscene5 - qt 5 , qtquick 2 Sounds like a plan. Any other supporters? I don't mind either way. I've done it the way I did because: [qml1plugindump had already been renamed] and I simply followed the logic that was already there. -- 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] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 08.47.08, Ziller Eike wrote:
Another thing that comes to my mind, that will break when renaming tools,
instead of installing links in paths like /usr/bin and keeping the the
tools unrenamed in specific version directories:
At the moment one can define an external tool in Qt Creator.
Configuration of these external tools is in Environment External Tools,
you can define any executable to run there with arguments etc, and a menu
item for the tool will be shown in Tools External.
E.g. we ship by default with an external tool definition for running lupdate
and lrelease, and the executable we run is defined as:
%{CurrentProject:QT_INSTALL_BINS}/lrelease
Qt Creator resolves that variable in there by taking the current project,
taking the current Qt version setting for that project, and asking that Qt
version for qmake -query QT_INSTALL_BINS.
At the moment that should work for Qt4 and Qt5.
If you rename lrelease to lrelease5 (or any other tool that we ship), this
is no longer possible and gets pretty fancy.
Having lrelease unrenamed in a different path would still require a change in
the definition, to %{CurrentProject:QT_INSTALL_LIBEXEC}/lrelease.
In any case, I think that lrelease and lupdate being run directly is the wrong
solution. They should be run by the Makefile, by having a correct .prf that
gets processed and adds the correct rules.
--
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] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 09.27.42, Poenitz Andre wrote: - The problem only exists on Linux * There are existing, working solutions to the problem there * There are skilled people (distro packagers) there perfectly capable of handling the problem * The majority of Qt users is not affected at all. - The solution is invasive. * Some of the follow-up changes are only triggered by the renaming E.g. the need to co-install lupdate does not exist yet, but is introduced by the qmake changes. * It affects any user project setup involving moc, uic, etc custom buildstep, like the ones all Qt using Visual Studio projects have, therefore eliminating the possibilty of having a code base running on both Qt 4 and Qt 5, and even hampering a direct Qt 4 - Qt 5 port. * Documentation needs to be adjusted. * Existing third party documentation of Qt in use, howto's, tutorials, in the *net lose value, because it will be not accurate anymore. Please add this factor into your analysis, then: Packagers WILL rename and there will be installations with renamed tools. How does that affect the documentation? How does that affect the existing setups? How does that tutorials, etc.? -- 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] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 08.52.47, Ziller Eike wrote: External tooling will need to deal with the new names. I don't see why. It's possible to ask qmake for the path where the other binaries, headers, examples, and a lot of other stuff are supposed to be: qmake -query. If we set the standards for distributions to have also e.g. /usr/lib/qt5/bin/qmake Yes, you can query qmake. But first you need to find it. Currently and for the next couple of years, that qmake is definitely not Qt 5's. It might be Qt 3's or Qt 4's, but will definitely not be Qt 5's. in addition to a symbolic link from /usr/bin/qmake to the current setting, a script can take qmake from the PATH (which can be set to whatever), and ask it where the other things are. A system-wide symlink is not a solution for people who aren't admins. Besides, that breaks multiple builds, for people who will be engaged in porting and need to try the older Qt 4 application at the same time as the newer Qt 5 one. The only solution that works is modifying PATH, with a script (it can't be done globally either, for the same reasons as above). I did propose that we move all binaries except qmake Why leave qmake out of the equation? See above. You need to find qmake in order to find the other tools. And qmake will not be Qt 5's. Therefore, we need another name for the tool that lets us find the other tools. Here's an idea: put *all* tools in libexec, including qmake, but install a new, global qt5-config. That tool allows one to find the rest, like: kde4-config --prefix python3 --prefix icu-config --prefix xslt-config --prefix mysql_config --prefix Or the other 47 that I have in my system: $ ls /bin/*[_-]config | wc -l 52 Note: such tool needs to work for multiarch too, unlike mysql_config. and the end-user applications to a libexec dir, which is basically what that dir of yours is. It didn't happen because, as I was starting this effort, I was convinced to go for the option of renaming everything instead: moc, uic, rcc, etc. are well- defined tools with well-defined interfaces, manuals, etc.. They are not internal helpers. [1] we already copy the .dll files because of that problem and the DLLs are much larger, so copying the executables is no big deal. -- 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] Summary of renaming changes
On 2012-10-19, Poenitz Andre andre.poen...@digia.com wrote: User support could then be: write qmake5 to build Qt 5 things no. it would be if you compiled Qt yourself or if you downloaded the built editions from digia, write qmake to build things. if you gotten from your linux distribution write probably qmake5, but maybe the distro chose some other naming scheme so it could also be qmake-qt5 or /usr/lib/ia64-linux-gnu/qt5/bin/qmake /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 07.31.21, Knoll Lars wrote: qdbusxml2cpp - qdbusxml2cpp5 qdbuscpp2xml - qdbuscpp2xml5 Do we need to rename the dbus tools? They are compatible afaik. Slightly... There's one change, which is the change on the annotations from com.trolltech to org.qtproject (yes, without the dash). The Qt 4 version of the tool warns but accepts the old name, the Qt 5 version errors out. I can bring it back to compatibility though. I'll also add a --qt5 option that is currently ignored to both versions, for future use. But the name changes should be mostly invisible to developers as the tools are being called by the build system. lconvert- lconvert5 lrelease- lrelease5 lupdate - lupdate5 These tools are in-between, as they IMO get called both by build systems as well as by developers directly. But if they are not compatible with Qt 4, we can't really have the same name unfortunately. Indeed. Right now, they produce the same output, as far as I understand, but Ossi says he cannot guarantee that it will remain like that. What's more, both lrelease and lupdate now try to parse .pro files and they run qmake for that. Those two are definitely not backwards compatible anymore. -- 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] Summary of renaming changes
On 19/10/12 19:27, Poenitz Andre wrote: I started -2'ing the changes, based on the outcome of a cost/benefit analysis: thank you. -- Lorn Potter Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On Fri, Oct 19, 2012 at 05:32:43PM +, Sune Vuorela wrote: On 2012-10-19, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: I have, as a distributor, frequently gotten 'hate' in #qt for providing switchable qmakes. using (debian style) altenatives for that is pretty stupid. I guess that proves my point quite good... as i've already written about three times, this is an argument for you guys finally agreeing on something and actually sticking to it, not upstream forcing this change on *all* users. Assuming distro1 needs change A and B to be applied to be in line with distro policies, distro2 needs change B and C, and distro 3 needs change D and E, and all distros want to do as little changes to upstream as possible... I guess distros and stuff could do a permanent fork thingie, but do we, as in Qt Project actually want to encourage that? Like go-oo.org? like eglibc? like ... Really. I really want, both as a Qt contributor and a Qt packager to ship a pristine Qt. Please help me make it happen. The proposal to put all unrenamed binaries in a directory and set up *5 links in /usr/bin to those _unmodified_ binaries was on the table. I haven't seen any reasoning that this is unusable as proper solution. In any case, you as packager are in a very specific situation. There are only a few of you, and I understand you do carry a burden, and I am not opposed to the idea of reducing that burden, if reasonably possible. Demanding to be relieved from that burden is one thing. Demanding to use an approach that will break thousands of other projects is a different one. It is unreasonable. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On 2012-10-19, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: Really. I really want, both as a Qt contributor and a Qt packager to ship a pristine Qt. Please help me make it happen. Demanding to be relieved from that burden is one thing. Demanding to use an approach that will break thousands of other projects is a different one. It is unreasonable. I am a bit saddened by this paragraph. I'm not demanding anything. I'm *explaining* my situation *hoping* that we can do something. I could also be *begging* if *you* would prefer that, but I wouldn't expet that. I do know that I can't *demand* anything. I do know, though, that the only way Qt can ensure the same is done on all distributions is to solve it in Qt. I will try hard, if the distributions need to solve it, to ensure that most distros implement it the same way. but I also can't demand anything there. And I have already heard people saying that qmake-qt5 is a much better name. Oh. btw, whattabout a solution with all tools having a 5 suffixed in /usr/bin and then creating a symlink farm somewhere with unversioned tools for people who has special needs? /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On Fri, Oct 19, 2012 at 08:02:46PM +, Sune Vuorela wrote: On 2012-10-19, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: Really. I really want, both as a Qt contributor and a Qt packager to ship a pristine Qt. Please help me make it happen. Demanding to be relieved from that burden is one thing. Demanding to use an approach that will break thousands of other projects is a different one. It is unreasonable. I am a bit saddened by this paragraph. I'm not demanding anything. I'm *explaining* my situation *hoping* that we can do something. Sorry if this came out more personal than it was intended. I could also be *begging* if *you* would prefer that, but I wouldn't expet that. I don't expect or want begging. It would be sufficient if proposals that clearly increase total pain when taking all users into account would not need to be discussed. [...] Oh. btw, whattabout a solution with all tools having a 5 suffixed in /usr/bin and then creating a symlink farm somewhere with unversioned tools for people who has special needs? The solution out-of-path-dir-with-binaries + links allows an arbitrary number of fully functional Qt builds being present, not just for major versions, but also for different configutations of the same version, easy selection between such builds by modifying PATH, and does not hurt non-Linux users. The solution of putting renamed binaries in the path (with or without additional symlinks) allows only one set of binaries, or, at the very least makes on such set special. Moreover, the renaming as such introduces problems, see the comments on gerrit. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 21.34.11, André Pönitz wrote: The proposal to put all unrenamed binaries in a directory and set up *5 links in /usr/bin to those unmodified binaries was on the table. I haven't seen any reasoning that this is unusable as proper solution. It is a solution. We can very well do that. My only argument is that this directory of old names is not very useful. Since we can't guarantee it will be on $PATH, we need to change all of our documentation. So it serves only for us old timers who have lots of muscle memory, but who are usually the most capable in creating shell aliases. But I'll happily implement those changes if it helps! -- 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] Summary of renaming changes
On Oct 19, 2012, at 11:31 PM, Thiago Macieira thiago.macie...@intel.com wrote: On sexta-feira, 19 de outubro de 2012 21.34.11, André Pönitz wrote: The proposal to put all unrenamed binaries in a directory and set up *5 links in /usr/bin to those unmodified binaries was on the table. I haven't seen any reasoning that this is unusable as proper solution. It is a solution. We can very well do that. My only argument is that this directory of old names is not very useful. Since we can't guarantee it will be on $PATH, we need to change all of our documentation. So it serves only for us old timers who have lots of muscle memory, but who are usually the most capable in creating shell aliases. There were some other arguments saying that this will also make our life easier on the tooling side, as e.g. creator relies on these names currently. If not we'll need a lot of magic in creator to figure out the name of the tool depending on the Qt version being used. This probably makes adding a Qt 4 target to Qt Creator later on a lot easier. But I'll happily implement those changes if it helps! It sounds like it will be more easy to accept for most people here. And it actually helps with all the Qt developers that will have to deal with Qt 4 and Qt5 builds in different directories. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 21.55.59, Knoll Lars wrote: My only argument is that this directory of old names is not very useful. Since we can't guarantee it will be on $PATH, we need to change all of our documentation. So it serves only for us old timers who have lots of muscle memory, but who are usually the most capable in creating shell aliases. There were some other arguments saying that this will also make our life easier on the tooling side, as e.g. creator relies on these names currently. If not we'll need a lot of magic in creator to figure out the name of the tool depending on the Qt version being used. This probably makes adding a Qt 4 target to Qt Creator later on a lot easier. Here's we might do then: QT_INSTALL_BINS - remains as it is, points to (on distros) /usr/lib/qt5/bin, contains unrenamed executables. QT_INSTALL_SYSTEM_BINS - points to /usr/bin and contains qmake5 (at least). As I said, I don't care if this is the main executable or a symlink to something else, as long as it exists, works and is official. Please note that we cannot expect QT_INSTALL_BINS to be in $PATH, so we need to change the documentation anyway. Either we point to the executables with their new and global names, or we document how to find them. But I'll happily implement those changes if it helps! It sounds like it will be more easy to accept for most people here. And it actually helps with all the Qt developers that will have to deal with Qt 4 and Qt5 builds in different directories. -- 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] Summary of renaming changes
On 18 October 2012 16:30, Thiago Macieira thiago.macie...@intel.com wrote: The following tools require more information: qdoc: not renamed because the Qt 4 version was called qdoc3 qhelpgenerator, qcollectiongenerator, qhelpconverter: they apparently keep backwards compatibility, so they should replace the Qt 4 versions qglinfo: new tool from qt3d I would add 5 everywhere for consistency... The following are user applications and they have not and will not be renamed: qdbus qdbusviewer assistant designer linguist creator pixeltool I would remove creator from this list as it's a different product and comes with its own versioning and release cycle -- are all of those 100% compatible with Qt 4? (First thing that comes to mind is that designer loads plugins...). Otherwise, I would rename them as well to enable coinstallation. Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On 2012-10-18, Giuseppe D'Angelo dange...@gmail.com wrote: The following are user applications and they have not and will not be renamed: qdbus qdbusviewer assistant designer linguist creator pixeltool I would remove creator from this list as it's a different product I would also remove designer from this list. Designer loads plugins and you need the plugins matching the thing you are desiging for. But beside that, I really applaud this effort. /Sune - one of those pesky distributors ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On quinta-feira, 18 de outubro de 2012 18.23.38, Olivier Goffart wrote: I agree with Ossi on this matter. I will add that i don't like to rename qmake to qmake5 because: One runs firefox, not firefox15. Firefox is an end-user application. You upgrade it and you don't keep the older version around. That's like Creator, Designer, Linguist and Assistant. Those aren't getting renamed. Then you will say firefox is different because you don't want different version of firefox? But what about web designer who want to test their website? You may say it is less common. I say most user don't need qmake which is in a dev package on many distributions. Only developpers need, and they probably only need one of them. Same for g++, they did not rename when binary compatibility was broken. Take the most recent example of python. They did not rename the executable. Some distribution renamed the new one to python3, some other (archlinux) renamed the old one python2. Let the distributions solve the distributor's problem. Let me be very clear: the distributions aren't fixing the distribution's problem. They'd be fixing *ours*. Like I said in another email: qmake will be renamed. That's what people will have when they come into #qt, interest@ or other forums. That means we help- givers need to know how the distributions have renamed and how they've done it. I'd much rather that they didn't apply patches and that everyone had the same solution. So stop being reactive and let's just fix this problem once and for all. -- 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] Summary of renaming changes
On Oct 18, 2012, at 5:30 PM, Thiago Macieira wrote: After all of my patches are integrated, here are the changes that will happen: - bin: The following tools have been renamed: qmake - qmake5 moc - moc5 uic - uic5 rcc - rcc5 qdbusxml2cpp - qdbusxml2cpp5 qdbuscpp2xml - qdbuscpp2xml5 lconvert - lconvert5 lrelease - lrelease5 lupdate - lupdate5 xmlpatterns - xmlpatterns5 xmlpatternsvalidator - xmlpatternsvalidator5 qmlviewer - qml1viewer This should be just qmlviewer (as it was in Qt 4.8).. I dont see a reason for this renaming.. [qml1plugindump had already been renamed] This should be reverted back to qmlplugindump .. (Same reason as above.. For QtQuick2, the related binaries can be renamed to qml2* (to reflect the version change) qmlscene - qml2scene This should be qml2viewer. qmlplugindump - qml2plugindump qmlbundle - qml2bundle qmlmin - qml2min qmlprofiler - qml2profiler qmltestrunner - qml2testrunner The following tools require more information: qdoc: not renamed because the Qt 4 version was called qdoc3 qhelpgenerator, qcollectiongenerator, qhelpconverter: they apparently keep backwards compatibility, so they should replace the Qt 4 versions qglinfo: new tool from qt3d The following are user applications and they have not and will not be renamed: qdbus qdbusviewer assistant designer linguist creator pixeltool - lib: All libraries are now called libQt5Name.so.5 on Unix systems, libQt5Name(_debug).5.dylib on Mac, Qt5Name(d).dll on Windows. This also applies to the qmake .prl files, the libtool .la files and the pkg-config .pc files. The cmake files had already had the 5. EXCEPT in Mac Framework builds. Since the header search path takes the framework's name, for source compatibility, the framework builds did not get the 5 in the name. - include: No change. - doc: On Windows builds and on -no-prefix-install builds, no change. Otherwise, the default install path is now $prefix/share/qt5/doc. Question: should it be $prefix/doc/qt5 to match autoconf's default? - mkspecs: On Windows builds, on -no-prefix-install builds, and on builds with -hostprefix, no change. Otherwise, the default install path is now $prefix/lib/qt5/mkspecs. - plugins: The default install path is now $prefix/lib/qt5/plugins on all systems. - imports: The default install path is now $prefix/lib/qt5/imports on all systems. It applies to QML 1 and Qt Quick 1 only. QML2 imports go to qmldir, which defaults to $prefix/lib/qt5/qml on all systems. -- Thiago Macieira - thiago.macieira (AT) intel.comhttp://intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.orgmailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Aurindam Jana, Software Engineer - Digia, Qt Don't Panic! Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On 18 October 2012 17:23, Olivier Goffart oliv...@woboq.com wrote: Take the most recent example of python. They did not rename the executable. Some distribution renamed the new one to python3, some other (archlinux) renamed the old one python2. Let the distributions solve the distributor's problem. With the net result that a script with a #!/usr/bin/python , written for python2, now calls python3 and may break? Hasn't it happened to qtjsbackend / qtwebkit? This is a moot point. Distributions don't support multiple versions of Firefox, as it's an ordinary end-user application, therefore there's no problem there. If an user wants to install multiple, system-wide versions of Firefox, then has to figure out how to do that on his/her own. Some distributions do support multiple versions of GCC by installing them in different paths AND having different executable names in /usr/bin, with gcc or g++ symlinks. But distributions don't support multiple versions of libc, multiple versions of libgcc, etc. It's reasonable to estimate that distributions will have to support coinstallation of Qt 4 + Qt 5 for the next 5-7 years. It's reasonable that the Qt project will have to support Qt 4 + Qt 5 for the next N years. What's our cost in renaming tools+libs now, once for all, versus the cost for every packager to rename/move things and test that they still work? What's our cost in documenting call qmake5 (which will work everywhere) vs. documenting call qmake and getting feedbacks such as it doesn't work what does qmake -v say Qt 3? Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On quinta-feira, 18 de outubro de 2012 17.47.16, Giuseppe D'Angelo wrote: The following are user applications and they have not and will not be renamed: qdbus qdbusviewer assistant designer linguist creator pixeltool I would remove creator from this list as it's a different product and comes with its own versioning and release cycle -- are all of those 100% compatible with Qt 4? (First thing that comes to mind is that designer loads plugins...). Otherwise, I would rename them as well to enable coinstallation. I added Creator to the list so that I could answer this exact question: Does anyone here think we should have two versions of Creator installed, one for developing Qt 4 applications and one for developing Qt 5 ones? Creator needs *some* solution of some kind so that its Designer component can work for Qt 4 and Qt 5. One solution is to run designer out-of-process so that it can load the proper plugins -- this also solves the problem of the MinGW / MSVC incompatibility on Windows. This would require having designer renamed. Another solution is to require the plugin upgrade, but continue to generate backwards-compatible .ui files. That is, the plugin that provides KListWidget should be upgraded too, to work in Qt 5, but continue to generate .ui data that Qt 4's uic can understand and generate proper code for. When I questioned briefly the Creator devs, they didn't seem too inclined to do former option. That means we're going to require the second, moving the burden to the plugin developers. -- 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] Summary of renaming changes
On 18.10.2012, at 18:47, Giuseppe D'Angelo wrote: On 18 October 2012 16:30, Thiago Macieira thiago.macie...@intel.com wrote: The following tools require more information: qdoc: not renamed because the Qt 4 version was called qdoc3 qhelpgenerator, qcollectiongenerator, qhelpconverter: they apparently keep backwards compatibility, so they should replace the Qt 4 versions qglinfo: new tool from qt3d I would add 5 everywhere for consistency... The following are user applications and they have not and will not be renamed: qdbus qdbusviewer assistant designer linguist creator pixeltool I would remove creator from this list as it's a different product and comes with its own versioning and release cycle -- are all of those 100% compatible with Qt 4? (First thing that comes to mind is that designer loads plugins...). Otherwise, I would rename them as well to enable coinstallation. Distributors can use whatever Qt version (in some limits) they want to compile Qt Creator. Afaik the integrated designer loads plugins from where ever the Qt that compiled it (+qt.config etc) tells it to find them. -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On Thu, Oct 18, 2012 at 05:47:16PM +0100, Giuseppe D'Angelo wrote: On 18 October 2012 16:30, Thiago Macieira thiago.macie...@intel.com wrote: The following tools require more information: qdoc: not renamed because the Qt 4 version was called qdoc3 qhelpgenerator, qcollectiongenerator, qhelpconverter: they apparently keep backwards compatibility, so they should replace the Qt 4 versions qglinfo: new tool from qt3d I would add 5 everywhere for consistency... +1 -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On Thu, Oct 18, 2012 at 08:30:03AM -0700, Thiago Macieira wrote: lconvert- lconvert5 lrelease- lrelease5 lupdate - lupdate5 Sorry, I don't get the joke. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 01.03.29, André Pönitz wrote: On Thu, Oct 18, 2012 at 08:30:03AM -0700, Thiago Macieira wrote: lconvert- lconvert5 lrelease- lrelease5 lupdate - lupdate5 Sorry, I don't get the joke. Because it was no joke. It's serious. -- 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] Summary of renaming changes
On quinta-feira, 18 de outubro de 2012 08.30.03, Thiago Macieira wrote: xmlpatterns - xmlpatterns5 xmlpatternsvalidator - xmlpatternsvalidator5 I've changed my mind on those two and dropped the patches that dealt with them. Those two are end-user applications and retain full backwards compatibility. They operate just like xmllint and xsltproc and so there's no need for co- installation. Therefore, there's no need to add 5 to their names. Distributions will simply have to upgrade the Qt 4 files with the Qt 5 ones. -- 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] Summary of renaming changes
On Thu, Oct 18, 2012 at 10:16:37AM -0700, Thiago Macieira wrote: I would remove creator from this list as it's a different product and comes with its own versioning and release cycle -- are all of those 100% compatible with Qt 4? (First thing that comes to mind is that designer loads plugins...). Otherwise, I would rename them as well to enable coinstallation. I added Creator to the list so that I could answer this exact question: Does anyone here think we should have two versions of Creator installed, one for developing Qt 4 applications and one for developing Qt 5 ones? I personally don't think so. Pretty much for the same reason that it does not seem to be overly prudent to have different versions of Creator for gcc 4.6 and 4.7, wxWidgets 2.8 and 2.9, boost 1.50 and 1.51, or Thursdays and Fridays. Creator needs *some* solution of some kind so that its Designer component can work for Qt 4 and Qt 5. Why? _You_ call Widgets done. Why do you suddenly care how people handle them? One solution is to run designer out-of-process so that it can load the proper plugins -- this also solves the problem of the MinGW / MSVC incompatibility on Windows. This would require having designer renamed. The MinGW/MSVC compatibility has been solved, or ignored, in various ways during the last three years. None of the approaches involved renaming the Designer binary, and it's not really clear how a 'Designer5.exe' would help to solve the problem. There have been incompatibilies in the Qt 4 era, too, and I am not aware of a distribution renaming Designer into Desiger42 and Designer43 or similar, just because they generated and/or crashed on incompatible .ui files. Another solution is to require the plugin upgrade, but continue to generate backwards-compatible .ui files. That is, the plugin that provides KListWidget should be upgraded too, to work in Qt 5, but continue to generate .ui data that Qt 4's uic can understand and generate proper code for. When I questioned briefly the Creator devs, they didn't seem too inclined to do former option. That means we're going to require the second, moving the burden to the plugin developers. Which, incidentally, has worked for a few years already. Designer plugins are not mandatory for successful use of Qt, not even for using Designer, let alone Creator. You are trying to solve a problem that does not exist in practice. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On Thu, Oct 18, 2012 at 04:10:16PM -0700, Thiago Macieira wrote: On sexta-feira, 19 de outubro de 2012 01.03.29, André Pönitz wrote: On Thu, Oct 18, 2012 at 08:30:03AM -0700, Thiago Macieira wrote: lconvert- lconvert5 lrelease- lrelease5 lupdate - lupdate5 Sorry, I don't get the joke. Because it was no joke. It's serious. What practical difference exists between calling a Qt 4 based lconvert and a Qt 5 based lconvert? What practical difference exists between calling a Qt 4 based lconvert and a Qt 5 based lconvert _that justifies changing the name_? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On 19/10/12 01:30, Thiago Macieira wrote: After all of my patches are integrated, here are the changes that will happen: - bin: The following tools have been renamed: So... You just don't care about the calls from myself and others to leave the names alone instead install newly-named (aliased) things into common directories (ie. /usr/bin) as is standard practice for other things that get co-installed? eg. /usr/bin -- something special has to be done here, (eg. qmake-qt5 or qmake as a symlink to a specific Qt install) /usr/lib/qt5/bin -- binaries go here with their NORMAL names -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 01.44.18, André Pönitz wrote: Creator needs *some* solution of some kind so that its Designer component can work for Qt 4 and Qt 5. Why? _You_ call Widgets done. Why do you suddenly care how people handle them? Done still means people can design new applications using the functionality. So people can use Designer in 2013. We still support it and we need to, therefore, keep it working. Even if the solution is: Another solution is to require the plugin upgrade, but continue to generate backwards-compatible .ui files. That is, the plugin that provides KListWidget should be upgraded too, to work in Qt 5, but continue to generate .ui data that Qt 4's uic can understand and generate proper code for. When I questioned briefly the Creator devs, they didn't seem too inclined to do former option. That means we're going to require the second, moving the burden to the plugin developers. Which, incidentally, has worked for a few years already. Designer plugins are not mandatory for successful use of Qt, not even for using Designer, let alone Creator. You are trying to solve a problem that does not exist in practice. The problem does exist, but so does the solution and it's already in place. Therefore we don't need to do anything. That's why designer is not getting renamed. The Qt 5 version simply replaces the Qt 4 one and, provided the plugins are upgraded too, no functionality is lost. -- 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] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 01.57.16, André Pönitz wrote: On Thu, Oct 18, 2012 at 04:10:16PM -0700, Thiago Macieira wrote: On sexta-feira, 19 de outubro de 2012 01.03.29, André Pönitz wrote: On Thu, Oct 18, 2012 at 08:30:03AM -0700, Thiago Macieira wrote: lconvert- lconvert5 lrelease- lrelease5 lupdate - lupdate5 Sorry, I don't get the joke. Because it was no joke. It's serious. What practical difference exists between calling a Qt 4 based lconvert and a Qt 5 based lconvert? Probably none. What practical difference exists between calling a Qt 4 based lconvert and a Qt 5 based lconvert _that justifies changing the name_? Today? None. However, the maintainer for those particular tools is disinclined to promise that they will remain compatible with Qt 4. -- 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] Summary of renaming changes
On 19/10/12 02:23, Olivier Goffart wrote: On Thursday 18 October 2012 08:30:03 Thiago Macieira wrote: After all of my patches are integrated, here are the changes that will happen: - bin: The following tools have been renamed: qmake - qmake5 moc - moc5 uic - uic5 rcc - rcc5 qdbusxml2cpp - qdbusxml2cpp5 qdbuscpp2xml - qdbuscpp2xml5 lconvert- lconvert5 lrelease- lrelease5 lupdate - lupdate5 xmlpatterns - xmlpatterns5 xmlpatternsvalidator - xmlpatternsvalidator5 [...] Thiago, I think you are going to ruin Qt5 the same way one could ruin a nuclear powerplant by installing an ugly pink bikesheet in front of it. I agree with Ossi on this matter. I will add that i don't like to rename qmake to qmake5 because: One runs firefox, not firefox15. Then you will say firefox is different because you don't want different version of firefox? But what about web designer who want to test their website? You may say it is less common. I say most user don't need qmake which is in a dev package on many distributions. Only developpers need, and they probably only need one of them. Same for g++, they did not rename when binary compatibility was broken. Take the most recent example of python. They did not rename the executable. Some distribution renamed the new one to python3, some other (archlinux) renamed the old one python2. Let the distributions solve the distributor's problem. +1 -- Lorn Potter Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On sexta-feira, 19 de outubro de 2012 10.17.39, Lincoln Ramsay wrote: On 19/10/12 01:30, Thiago Macieira wrote: After all of my patches are integrated, here are the changes that will happen: - bin: The following tools have been renamed: So... You just don't care about the calls from myself and others to leave the names alone instead install newly-named (aliased) things into common directories (ie. /usr/bin) as is standard practice for other things that get co-installed? I'm not ignoring. I was just summarising the effort I've done so far. I'm posting it so we can review it and correct further, if needed. eg. /usr/bin -- something special has to be done here, (eg. qmake-qt5 or qmake as a symlink to a specific Qt install) /usr/lib/qt5/bin -- binaries go here with their NORMAL names Thanks, but I don't think that solves many problems. That extra path would exist only for people like you or I who are used to them. I don't see further use for them. Here's why: External tooling will need to deal with the new names. For example, a buildsystem needs to search for qmake5 or qmake-qt5. And it needs to find qmake so that it can query where the other binaries are located, as they could be in: /usr/lib/qt5/bin /usr/lib64/qt5/bin /usr/lib/i386-linux-gnu/qt5/bin /usr/local/lib/qt5/bin /home/thiago/obj/qt/qt5/qtbase/lib/qt5/bin and so forth The tool cannot depend on the legacy path being on $PATH or that, if it is on $PATH, that the Qt 5 path comes before the Qt 4 one. Besides, we as helpgivers cannot depend on that either when giving advice: we need to tell people to run qmake5. What's more, this creates more work for us (well, for me, since I'm the one doing this). Adding symlinks in either direction is very hard, especially since they don't work on Windows. The tool would need to be copied instead[1]. I did propose that we move all binaries except qmake and the end-user applications to a libexec dir, which is basically what that dir of yours is. It didn't happen because, as I was starting this effort, I was convinced to go for the option of renaming everything instead: moc, uic, rcc, etc. are well- defined tools with well-defined interfaces, manuals, etc.. They are not internal helpers. [1] we already copy the .dll files because of that problem and the DLLs are much larger, so copying the executables is no big deal. -- 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
