Re: [Development] New proposal for the tool naming
Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build You definitely don't want support multiarch configurations out-of-the-box :) Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5 /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86` (or even with `qmake -set-qt 5x86` if you created a symlink to the 5.0-x86's config file). And yeah, switching the system-default Qt for all users just to build some crappyhelloworldexample .pro is a shiny new great idea :) Konstantin 2012/10/24 Lincoln Ramsay a1291...@gmail.com: On 24/10/12 04:33, Thiago Macieira wrote: I think we are keeping it simple. The current proposal is the simplest that still works. If you can come up with something even simpler, I'll gladly accept it. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? Drop it. I know I complained about renaming qmake but... it would be simpler to rename qmake to qmake5 than to have a 'special' qmake that may or may not be the qmake that's first in your PATH and that may or may not do something with a -qtx switch. So I'm going to remove my +1 for the 'special' qmake and instead suggest a much simpler solution. This is just for 'qmake' though, everything else... same as it was before. Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build Optional: Create libexec/bin/qmake as a symlink to qmake5 (for Windows... a .bat or .cmd may work, else a copy). The officially supported way to build thus becomes qmake5 and it is guaranteed to work no matter what platform you're on or how you've set your PATH. Yes, we have to update all the documentation. The optional symlink is for complainers like me, so we can continue to run qmake - but only if we set PATH correctly first. It'll also help with old instructions, scripts, etc. that would break if we just renamed qmake ;) -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On 23 Oct 2012, at 19:03, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote: So that if you happen to have a real qmake instead of the wrapper in the PATH on linux, you don't realize that when you are doing qmake -qt5 to force most current qt5 version (or whatever the semantics would be), you actually execute a completely different qmake? I don't think that would be a good idea. It will do that too if it's in a separate build looking at a non-standard configuration path. I don't get what you mean with that. Er... convoluted way of saying that if you only have one Qt build visible from the wrapper, qmake -qt5 can mean exactly one Qt build. Therefore, by exclusion of any other alternatives, it's the most recent build available :-) In any case, -qt5 may not mean latest, but simply default 5.x version. The implementation will decide what that means. qmake -qt5 would *not* mean default or latest (whatever the implementation will decide), if there is a specific version of qmake in the PATH, instead of the wrapper. From a usability standpoint it would be much safer to bail out with an error if you use qmake -qtXYZ on a specific version of qmake instead of the wrapper, because it wouldn't do what you'd expect it to do. That's mostly what's going to happen on Windows anyway, isn't it? My concerns are about having -qt5 ignored for the real qmake on linux. On Windows and Mac the -qt option is useless anyhow (which makes it questionable to use it there IMO, so it makes it questionable to use it in the documentation that way too IMO) I think all this becomes much too confusing. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? Because you wouldn't be able to use -qt4 or -qt=5.0.1. You don't want to just document it (as in qmake (the wrapper on Linux) also takes the -qt[=version] option), but want to use it everywhere in the documentation where qmake is called. That creates expectations about how qmake works, though it is just referring to how the qmake wrapper on Linux works. -- 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] New proposal for the tool naming
On 24 Oct 2012, at 08:04, Konstantin Ritt ritt...@gmail.com wrote: Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build You definitely don't want support multiarch configurations out-of-the-box :) Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5 /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86` (or even with `qmake -set-qt 5x86` if you created a symlink to the 5.0-x86's config file). And yeah, switching the system-default Qt for all users just to build some crappyhelloworldexample .pro is a shiny new great idea :) qmake -set… would/should/must certainly set a *user* specific default. (There'd need to be other mechanisms for distributors and admins to set the system wide default.) Konstantin 2012/10/24 Lincoln Ramsay a1291...@gmail.com: On 24/10/12 04:33, Thiago Macieira wrote: I think we are keeping it simple. The current proposal is the simplest that still works. If you can come up with something even simpler, I'll gladly accept it. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? Drop it. I know I complained about renaming qmake but... it would be simpler to rename qmake to qmake5 than to have a 'special' qmake that may or may not be the qmake that's first in your PATH and that may or may not do something with a -qtx switch. So I'm going to remove my +1 for the 'special' qmake and instead suggest a much simpler solution. This is just for 'qmake' though, everything else... same as it was before. Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build Optional: Create libexec/bin/qmake as a symlink to qmake5 (for Windows... a .bat or .cmd may work, else a copy). The officially supported way to build thus becomes qmake5 and it is guaranteed to work no matter what platform you're on or how you've set your PATH. Yes, we have to update all the documentation. The optional symlink is for complainers like me, so we can continue to run qmake - but only if we set PATH correctly first. It'll also help with old instructions, scripts, etc. that would break if we just renamed qmake ;) -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- 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] New proposal for the tool naming
Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build You definitely don't want support multiarch configurations out-of-the-box :) Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5 /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86` (or even with `qmake -set-qt 5x86` if you created a symlink to the 5.0-x86's config file). And yeah, switching the system-default Qt for all users just to build some crappyhelloworldexample .pro is a shiny new great idea :) qmake -set… would/should/must certainly set a *user* specific default. (There'd need to be other mechanisms for distributors and admins to set the system wide default.) if we're talking about the new qmake wrapper, then yes, certainly. however, the system wide default Qt version could be set by the distributor easily with that qmake wrapper as well by simply replacing the default Qt version's config file somewhere at /etc/qmake (?) - they could even have some default symlink there that would point to the real config file of choice. so, if we're on multilib, thenthe distributor would point /etc/qmake/default to, say, qt5-unknown-linux-x86_64. such an ability makes the distributor's life easier whilst the system wide default version could be managed by the alternatives tools I know. on the other hand, having a /usr/bin/qmake5 symlink doesn't solve any issues on multilib - we still need /usr/bin/qmake5-x86 in this case. Konstantin 2012/10/24 Ziller Eike eike.zil...@digia.com: On 24 Oct 2012, at 08:04, Konstantin Ritt ritt...@gmail.com wrote: Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build You definitely don't want support multiarch configurations out-of-the-box :) Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5 /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86` (or even with `qmake -set-qt 5x86` if you created a symlink to the 5.0-x86's config file). And yeah, switching the system-default Qt for all users just to build some crappyhelloworldexample .pro is a shiny new great idea :) qmake -set… would/should/must certainly set a *user* specific default. (There'd need to be other mechanisms for distributors and admins to set the system wide default.) Konstantin 2012/10/24 Lincoln Ramsay a1291...@gmail.com: On 24/10/12 04:33, Thiago Macieira wrote: I think we are keeping it simple. The current proposal is the simplest that still works. If you can come up with something even simpler, I'll gladly accept it. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? Drop it. I know I complained about renaming qmake but... it would be simpler to rename qmake to qmake5 than to have a 'special' qmake that may or may not be the qmake that's first in your PATH and that may or may not do something with a -qtx switch. So I'm going to remove my +1 for the 'special' qmake and instead suggest a much simpler solution. This is just for 'qmake' though, everything else... same as it was before. Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build Optional: Create libexec/bin/qmake as a symlink to qmake5 (for Windows... a .bat or .cmd may work, else a copy). The officially supported way to build thus becomes qmake5 and it is guaranteed to work no matter what platform you're on or how you've set your PATH. Yes, we have to update all the documentation. The optional symlink is for complainers like me, so we can continue to run qmake - but only if we set PATH correctly first. It'll also help with old instructions, scripts, etc. that would break if we just renamed qmake ;) -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- 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
Re: [Development] New proposal for the tool naming
On 24/10/12 4:04 PM, Konstantin Ritt wrote: You definitely don't want support multiarch configurations out-of-the-box :) Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5 /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86` (or even with `qmake -set-qt 5x86` if you created a symlink to the 5.0-x86's config file). And yeah, switching the system-default Qt for all users just to build some crappyhelloworldexample .pro is a shiny new great idea :) The original problem being solved is co-installation of Qt 4 + Qt 5 for Linux distros. How is any of the above relevant to that? If you want to solve all those other problems then sure, a symlink isn't enough but I'm not sure we need to solve all those other problems as part of the co-installation of Qt 4 + Qt 5 for Linux distros. You still have PATH, qset, etc. for selecting a specific build when there are multiple available. Work on this meta-qmake that calls through to one of many installed versions can still be done. Perhaps though, it's not something that needs to block the release of Qt 5.0. -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On Mon, Oct 22, 2012 at 01:38:56PM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 20.52.49, Oswald Buddenhagen wrote: I can't fix what's already broken due to the Qt 3 and Qt 4 mess. I can only fix going forward for Qt 5. i fail to see your argument here. what exactly is the reason why having the apps and the tools in the same bindir would be bad? Because qdbus should be in /usr/bin but the version- and arch-specific qmake should be somewhere in /usr/lib*/qt5. ok, i can buy that as such. however, i totally see no point in us doing this upstream, and why qmake (or even qlibraryinfo) should be in any way concerned with it. Symlinking the other tools is optional and should not be the default. as i said three times already, lupdate is usefully user-invokable, and the gui tools will be renamed by some distros anyway - so it is only reasonable to isolate and include them into the aliasing magic - always, to avoid fragmentation. So we provide symlinks for a few of the tools in addition to qmake, but I don't see why moc should be in $PATH. The number of people who actually run it manually must be countable in one hand. i'm pretty sure that *some* build systems rely on moc being in the path. one could argue that they are broken - but then, it exactly fits the /usr/bin philosophy, so it's hard to blame them. On the other hand (the one not counting people), applications like qdbus or xmlpatterns make no sense to have in duplication. actually, xmlpatterns (just like lupdate) can be usefully called both manually and from build scripts. i meant a qt tool without the symlink trick. you totally don't want to update all documentation to say qt qmake, etc., and as a user i positively don't want to type that. I do want to update all the documentation to say qmake -qt5. well, i'm pretty sure you didn't really think about that. otherwise i'd have to declare you insane. (all the documentation is a tad more than a few qdoc files). Yes, I really meant it. We have to start somewhere. it's official then: you are insane. :D anyway, i would think that both we and our users have better things to do ... and as you may have noticed, rewriting the book (in this case kinda literally) is typically met with skepticism, to put it mildly. I would prefer to have the tool inside qtbase, [...] since this tool is the entry point for building Qt5-based applications, it must either come with Qt or not depend upon it. actually, not at all. as we established, this is an entirely optional, external add-on. it's not necessary for building qt at all - the environment in which qt is built can be very well self-contained, as it has always been. i strongly prefer to have it outside qt itself. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
Re on adjusting all the documentation to say run qmake -qt5: Let's count who will have Qt5 co-/installed: 1) Those who's DE is built against Qt5 and thus Qt5 is the default Qt there; though, they may have Qt4 co-installed until all the qt-apps in-use are ported to Qt5; 2) Those who are still on Qt4-based DE but want some qt-apps where Qt5 is installed as a dependency (most-probably they'll have the libraries only); 3) Developers who need to build something against Qt5; 4) Ones who installs everything because they do not know what they are doing ;) Only 1) and 3) are the ones who do need qmake. In both cases, it seems to be safe to make Qt5 the default version that qmake is pointing to. Moreover, shouldn't we mention Qt5 as a drop-in replacement for Qt3/Qt4? So if the user does need to build something Qt based, let the latest system-wide Qt version be the default one! I fhe doesn't, he don't need qmake either. Summary: to me, it seems like keep saying run qmake in the docs is quite enough... kind regards, Konstantin 2012/10/23 Oswald Buddenhagen oswald.buddenha...@digia.com: On Mon, Oct 22, 2012 at 01:38:56PM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 20.52.49, Oswald Buddenhagen wrote: I can't fix what's already broken due to the Qt 3 and Qt 4 mess. I can only fix going forward for Qt 5. i fail to see your argument here. what exactly is the reason why having the apps and the tools in the same bindir would be bad? Because qdbus should be in /usr/bin but the version- and arch-specific qmake should be somewhere in /usr/lib*/qt5. ok, i can buy that as such. however, i totally see no point in us doing this upstream, and why qmake (or even qlibraryinfo) should be in any way concerned with it. Symlinking the other tools is optional and should not be the default. as i said three times already, lupdate is usefully user-invokable, and the gui tools will be renamed by some distros anyway - so it is only reasonable to isolate and include them into the aliasing magic - always, to avoid fragmentation. So we provide symlinks for a few of the tools in addition to qmake, but I don't see why moc should be in $PATH. The number of people who actually run it manually must be countable in one hand. i'm pretty sure that *some* build systems rely on moc being in the path. one could argue that they are broken - but then, it exactly fits the /usr/bin philosophy, so it's hard to blame them. On the other hand (the one not counting people), applications like qdbus or xmlpatterns make no sense to have in duplication. actually, xmlpatterns (just like lupdate) can be usefully called both manually and from build scripts. i meant a qt tool without the symlink trick. you totally don't want to update all documentation to say qt qmake, etc., and as a user i positively don't want to type that. I do want to update all the documentation to say qmake -qt5. well, i'm pretty sure you didn't really think about that. otherwise i'd have to declare you insane. (all the documentation is a tad more than a few qdoc files). Yes, I really meant it. We have to start somewhere. it's official then: you are insane. :D anyway, i would think that both we and our users have better things to do ... and as you may have noticed, rewriting the book (in this case kinda literally) is typically met with skepticism, to put it mildly. I would prefer to have the tool inside qtbase, [...] since this tool is the entry point for building Qt5-based applications, it must either come with Qt or not depend upon it. actually, not at all. as we established, this is an entirely optional, external add-on. it's not necessary for building qt at all - the environment in which qt is built can be very well self-contained, as it has always been. i strongly prefer to have it outside qt itself. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On terça-feira, 23 de outubro de 2012 15.04.10, Oswald Buddenhagen wrote: Because qdbus should be in /usr/bin but the version- and arch-specific qmake should be somewhere in /usr/lib*/qt5. ok, i can buy that as such. however, i totally see no point in us doing this upstream, and why qmake (or even qlibraryinfo) should be in any way concerned with it. We've been over this: because I'd rather do this right and once and for all. Who are the best people to make sure that all tools continue to work under those conditions? Upstream is. The alternative is that we're responsible for the configuration that dowsntreams use as well as the patches they may have had to apply to make it work. So we provide symlinks for a few of the tools in addition to qmake, but I don't see why moc should be in $PATH. The number of people who actually run it manually must be countable in one hand. i'm pretty sure that *some* build systems rely on moc being in the path. one could argue that they are broken - but then, it exactly fits the /usr/bin philosophy, so it's hard to blame them. We've been over this, again. If they rely on $PATH without user intervention, they are already broken, as /usr/bin/moc might be Qt 4's. But I'm not against wrapping the tools. On the other hand (the one not counting people), applications like qdbus or xmlpatterns make no sense to have in duplication. actually, xmlpatterns (just like lupdate) can be usefully called both manually and from build scripts. True, but unlike lupdate, the functionality, purpose and output do not change from version to version. The Qt 5 xmlpatterns cleanly replaces the old Qt 4 one. There's no need to duplicate. I do want to update all the documentation to say qmake -qt5. well, i'm pretty sure you didn't really think about that. otherwise i'd have to declare you insane. (all the documentation is a tad more than a few qdoc files). Yes, I really meant it. We have to start somewhere. it's official then: you are insane. :D anyway, i would think that both we and our users have better things to do ... and as you may have noticed, rewriting the book (in this case kinda literally) is typically met with skepticism, to put it mildly. Correcting 15 years of doing installations takes time and usually meets with resistance. I would prefer to have the tool inside qtbase, [...] since this tool is the entry point for building Qt5-based applications, it must either come with Qt or not depend upon it. actually, not at all. as we established, this is an entirely optional, external add-on. it's not necessary for building qt at all - the environment in which qt is built can be very well self-contained, as it has always been. i strongly prefer to have it outside qt itself. If we add the -qt5 option to the traditional qmake, then it can be considered optional. I still prefer to develop it inside qtbase. -- 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] New proposal for the tool naming
From: Thiago Macieira thiago.macie...@intel.com Subject: Re: [Development] New proposal for the tool naming On segunda-feira, 22 de outubro de 2012 21.21.17, André Pönitz wrote: On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald Buddenhagen wrote: On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote: Note: this applies to the *tools* only. The library naming and installation paths for plugins and QML files has remained uncontested so far, so we appear to have a consensus. only if you conveniently ignore my two (or three?) mails saying the exact opposite. the problem with renaming the libraries is the same as with tools: project files not based on qmake need to be adjusted. Indeed, but I contest that those changes are minor, expected and understandable. The vast majority of the users are probably using either qmake or cmake (99%?) and those are taken care of already. That would leave Visual Studio at less than 1%, which is certainly not in sync with any survey I've seen during the last ten years. I must confess I have no idea how many people are using Visual Studio today and I must also admit I have not a clue about how the add-in or qmake- generated .vcproj files work. But I can make one qualified assumption: if you can start Visual Studio from outside the Qt prompt, then those .vcproj files and the add-in must work -- somehow -- without depending on $PATH. That means they either hardcode a path or they find it somewhere in the registry. My guess is both: qmake hardcodes the paths in the .vcproj it generates and the add-in finds Qt through the registry. That would put them in Bucket B in my list. Qmake puts hard coded values into the VC Project files. The Visual Studios Plug-in, last I used it, puts in a referential value - $(QtDir) IIRC - that it defines, and is suppose to let you switch between versions. Where it finds the versions, I don't know. $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On 22 Oct 2012, at 17:11, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 22 de outubro de 2012 14.59.09, Ziller Eike wrote: Just as a side note, that requires that Windows and Mac to also have this tool, and e.g. on Windows to have that tool in the PATH and pointing to the corresponding Qt for the environment set up shell scripts. In the SDK, the tools/ directory might be a good place for it. It's easy to add a -qt5 ignored option to the regular qmake too. So that if you happen to have a real qmake instead of the wrapper in the PATH on linux, you don't realize that when you are doing qmake -qt5 to force most current qt5 version (or whatever the semantics would be), you actually execute a completely different qmake? I don't think that would be a good idea. It will do that too if it's in a separate build looking at a non-standard configuration path. I don't get what you mean with that. That's mostly what's going to happen on Windows anyway, isn't it? My concerns are about having -qt5 ignored for the real qmake on linux. On Windows and Mac the -qt option is useless anyhow (which makes it questionable to use it there IMO, so it makes it questionable to use it in the documentation that way too IMO) I think all this becomes much too confusing. -- 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] New proposal for the tool naming
On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote: So that if you happen to have a real qmake instead of the wrapper in the PATH on linux, you don't realize that when you are doing qmake -qt5 to force most current qt5 version (or whatever the semantics would be), you actually execute a completely different qmake? I don't think that would be a good idea. It will do that too if it's in a separate build looking at a non-standard configuration path. I don't get what you mean with that. Er... convoluted way of saying that if you only have one Qt build visible from the wrapper, qmake -qt5 can mean exactly one Qt build. Therefore, by exclusion of any other alternatives, it's the most recent build available :-) In any case, -qt5 may not mean latest, but simply default 5.x version. The implementation will decide what that means. That's mostly what's going to happen on Windows anyway, isn't it? My concerns are about having -qt5 ignored for the real qmake on linux. On Windows and Mac the -qt option is useless anyhow (which makes it questionable to use it there IMO, so it makes it questionable to use it in the documentation that way too IMO) I think all this becomes much too confusing. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? -- 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] New proposal for the tool naming
On terça-feira, 23 de outubro de 2012 18.29.34, Oswald Buddenhagen wrote: We've been over this: because I'd rather do this right and once and for all. Who are the best people to make sure that all tools continue to work under those conditions? Upstream is. the thing is that this is a non-change. *nothing* needs to be changed in the sources - it's only a question of where the package manager is told to put the executable. i don't see why we should introduce any complexity upstream for a problem that is cleanly solved by downstream for decades. You do realise that there has been *no* clean solution developed downstream, right? Much less for decades. Renaming qmake to qmake-qt4 is not a clean solution. Our heretofore requirement of changing PATH has been largely ignored by everyone on the Linux world, and has been applied to the Mac world only recently (up until the SDKs, we distributed globally-installed frameworks). History so far shows that if we don't do it, distributions won't do it cleanly either. I have much more confidence in them getting it right if *we* get it right for them. I'd much rather make it easier for them by making it so they have to do very little or nothing. I know packagers are intelligent people, but they're also busy people. Qt is hardly the only package they take care of. But it's one that takes a disproportionate amount of resources to maintain and also to build. i'm pretty sure that *some* build systems rely on moc being in the path. one could argue that they are broken - but then, it exactly fits the /usr/bin philosophy, so it's hard to blame them. We've been over this, again. If they rely on $PATH without user intervention, they are already broken, as /usr/bin/moc might be Qt 4's. they are not broken, because relying on a correctly set up $PATH is an entirely reasonable position. I beg to differ, again. That's the position we've been taking for the 15 years of the existence of moc and the 10 years of qmake, but we've not been listened to. We may think and we definitely have thought it was reasonable to ask. But history shows that we haven't been listened to. Therefore, it's not reasonable to *keep* asking. the problem you are trying to solve is limited to co-installation into a single path, which is a policy-imposed problem of linux distributions. it is incredibly silly to claim that something that does not comply with this policy is broken by definition. I understand and even agree with your interpretation: the brokenness isn't our doing, not alone anyway. Nevertheless, it is broken. Blame all you want the distributors. They won't change their policies for us or for the handful of other packages that aren't distro-friendly. We have a saying in Portuguese, dar murro em ponta de faca (roughly translates to punching the pointy edge of a knife), which applies to when one insists in doing something painful and clearly ill-advised. Insisting on our Qt 4 advice is that, since there's no indication our advice will be listened to any more than in the past. We tried, we failed. Time to try something different. True, but unlike lupdate, the functionality, purpose and output do not change from version to version. The Qt 5 xmlpatterns cleanly replaces the old Qt 4 one. There's no need to duplicate. your idea doesn't work anyway. the distros won't have the users install the qt5 libraries just because the user requested an xmlpatterns package, when a qt4-based xmlpatterns can be had almost for free for those which already have qt4 libs installed. and some distros won't have two alternative xmlpatterns packages which provide the same binary - because of non-conflict policies. the bottom line is that there will be qt version bound sets of all tools and apps, and that they will have to meet the co-installability requirements. The difference is that xmlpatterns, like qdbus and the other applications, can be updated by the Debian alternatives mechanism. They're just two different implementations of the same functionality. The solution for that problem already exists. The solution for the qmake problem does not, at least not a solution that has been applied. Though I want to hear from distros what they think of the fact that Designer is being put in the same bucket. -- 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] New proposal for the tool naming
From: Thiago Macieira thiago.macie...@intel.com Sent: Tuesday, October 23, 2012 1:03 PM Subject: Re: [Development] New proposal for the tool naming On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote: So that if you happen to have a real qmake instead of the wrapper in the PATH on linux, you don't realize that when you are doing qmake -qt5 to force most current qt5 version (or whatever the semantics would be), you actually execute a completely different qmake? I don't think that would be a good idea. It will do that too if it's in a separate build looking at a non-standard configuration path. I don't get what you mean with that. Er... convoluted way of saying that if you only have one Qt build visible from the wrapper, qmake -qt5 can mean exactly one Qt build. Therefore, by exclusion of any other alternatives, it's the most recent build available :-) In any case, -qt5 may not mean latest, but simply default 5.x version. The implementation will decide what that means. How is this any better then updating LSB/FHS with guidelines on how to properly install Qt on a Unix/Linux system? Is it not easier to simply say install to /usr/share/qt-5.0.0.0 with a symlink to /usr/share/qt5, and require that distro specific tools manage symlinks to qmake/etc in the path? Or even having /usr/share/qt in the path and simply manage a symlink to it? KISS is a very good principle, and I don't see it being applied in this discussion. Rather we are getting lots of if we do this we solve this, but then if we do that we solve that; and in all cases it is will cause headaches all around except for a few people. That's mostly what's going to happen on Windows anyway, isn't it? My concerns are about having -qt5 ignored for the real qmake on linux. On Windows and Mac the -qt option is useless anyhow (which makes it questionable to use it there IMO, so it makes it questionable to use it in the documentation that way too IMO) I think all this becomes much too confusing. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
How is this any better then updating LSB/FHS with guidelines on how to properly install Qt on a Unix/Linux system? Is it not easier to simply say install to /usr/share/qt-5.0.0.0 with a symlink to /usr/share/qt5, and require that distro specific tools manage symlinks to qmake/etc in the path? Or even having /usr/share/qt in the path and simply manage a symlink to it? DON'T propose one to install libraries to /usr/share - it is not /usr/lib! especially on multiarch/multilib. Konstantin 2012/10/23 BRM bm_witn...@yahoo.com: From: Thiago Macieira thiago.macie...@intel.com Sent: Tuesday, October 23, 2012 1:03 PM Subject: Re: [Development] New proposal for the tool naming On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote: So that if you happen to have a real qmake instead of the wrapper in the PATH on linux, you don't realize that when you are doing qmake -qt5 to force most current qt5 version (or whatever the semantics would be), you actually execute a completely different qmake? I don't think that would be a good idea. It will do that too if it's in a separate build looking at a non-standard configuration path. I don't get what you mean with that. Er... convoluted way of saying that if you only have one Qt build visible from the wrapper, qmake -qt5 can mean exactly one Qt build. Therefore, by exclusion of any other alternatives, it's the most recent build available :-) In any case, -qt5 may not mean latest, but simply default 5.x version. The implementation will decide what that means. How is this any better then updating LSB/FHS with guidelines on how to properly install Qt on a Unix/Linux system? Is it not easier to simply say install to /usr/share/qt-5.0.0.0 with a symlink to /usr/share/qt5, and require that distro specific tools manage symlinks to qmake/etc in the path? Or even having /usr/share/qt in the path and simply manage a symlink to it? KISS is a very good principle, and I don't see it being applied in this discussion. Rather we are getting lots of if we do this we solve this, but then if we do that we solve that; and in all cases it is will cause headaches all around except for a few people. That's mostly what's going to happen on Windows anyway, isn't it? My concerns are about having -qt5 ignored for the real qmake on linux. On Windows and Mac the -qt option is useless anyhow (which makes it questionable to use it there IMO, so it makes it questionable to use it in the documentation that way too IMO) I think all this becomes much too confusing. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On terça-feira, 23 de outubro de 2012 10.42.58, BRM wrote: In any case, -qt5 may not mean latest, but simply default 5.x version. The implementation will decide what that means. How is this any better then updating LSB/FHS with guidelines on how to properly install Qt on a Unix/Linux system? Is it not easier to simply say install to /usr/share/qt-5.0.0.0 with a symlink to /usr/share/qt5, and require that distro specific tools manage symlinks to qmake/etc in the path? Or even having /usr/share/qt in the path and simply manage a symlink to it? First of all, because we won't be able to get LSB/FHS to update for us. It just won't happen. And even if we did get that, note that distributions are even more strict than LSB/FHS, since most of them don't use /opt either. So this solution is better than updating because it's achievable. Possible is better than impossible. Second, because updating LSB/FHS isn't enough either. The user still needs to find the Qt 5 qmake somewhere to get started. Updating the documentation to list the full path is worse than updating it to add a -qt5 argument. Managing a symlink in /usr/bin is not an acceptable solution because that requires administrator permissions and it breaks the ability to easily switch between Qt 4 and Qt 5. KISS is a very good principle, and I don't see it being applied in this discussion. Rather we are getting lots of if we do this we solve this, but then if we do that we solve that; and in all cases it is will cause headaches all around except for a few people. I think we are keeping it simple. The current proposal is the simplest that still works. If you can come up with something even simpler, I'll gladly accept it. The stuff you proposed before isn't acceptable because I shot holes through them. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? Drop it. -- 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] New proposal for the tool naming
On Tue, Oct 23, 2012 at 10:18:38AM -0700, Thiago Macieira wrote: On terça-feira, 23 de outubro de 2012 18.29.34, Oswald Buddenhagen wrote: We've been over this: because I'd rather do this right and once and for all. Who are the best people to make sure that all tools continue to work under those conditions? Upstream is. the thing is that this is a non-change. *nothing* needs to be changed in the sources - it's only a question of where the package manager is told to put the executable. i don't see why we should introduce any complexity upstream for a problem that is cleanly solved by downstream for decades. You do realise that there has been *no* clean solution developed downstream, right? Much less for decades. Renaming qmake to qmake-qt4 is not a clean solution. [...] this paragraph was about splitting out apps from qt's common bin dir (which would be isolated anyway). therefore the rest of your response is misapplied. i'm pretty sure that *some* build systems rely on moc being in the path. one could argue that they are broken - but then, it exactly fits the /usr/bin philosophy, so it's hard to blame them. We've been over this, again. If they rely on $PATH without user intervention, they are already broken, as /usr/bin/moc might be Qt 4's. they are not broken, because relying on a correctly set up $PATH is an entirely reasonable position. I beg to differ, again. That's the position we've been taking for the 15 years of the existence of moc and the 10 years of qmake, but we've not been listened to. We may think and we definitely have thought it was reasonable to ask. But history shows that we haven't been listened to. Therefore, it's not reasonable to *keep* asking. this paragraph was about released 3rd party apps, and therefore entirely out of our control. we can only make it worse for them. True, but unlike lupdate, the functionality, purpose and output do not change from version to version. The Qt 5 xmlpatterns cleanly replaces the old Qt 4 one. There's no need to duplicate. your idea doesn't work anyway. the distros won't have the users install the qt5 libraries just because the user requested an xmlpatterns package, when a qt4-based xmlpatterns can be had almost for free for those which already have qt4 libs installed. and some distros won't have two alternative xmlpatterns packages which provide the same binary - because of non-conflict policies. the bottom line is that there will be qt version bound sets of all tools and apps, and that they will have to meet the co-installability requirements. The difference is that xmlpatterns, like qdbus and the other applications, can be updated by the Debian alternatives mechanism. yes, debian. have you checked that this is true for all relevant downstreams? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On Mon, Oct 22, 2012 at 01:46:09PM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 21.21.17, André Pönitz wrote: On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald Buddenhagen wrote: On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote: Note: this applies to the *tools* only. The library naming and installation paths for plugins and QML files has remained uncontested so far, so we appear to have a consensus. only if you conveniently ignore my two (or three?) mails saying the exact opposite. the problem with renaming the libraries is the same as with tools: project files not based on qmake need to be adjusted. Indeed, but I contest that those changes are minor, expected and understandable. The vast majority of the users are probably using either qmake or cmake (99%?) and those are taken care of already. That would leave Visual Studio at less than 1%, which is certainly not in sync with any survey I've seen during the last ten years. I must confess I have no idea how many people are using Visual Studio today and I must also admit I have not a clue about how the add-in or qmake- generated .vcproj files work. I'll try to find a number tomorrow. Until then simply assume we are talking about not-to-modest two-digit percentages. Moreover, it is a reasonable assumption that only few Qt based Windows-only projects supporting VS use qmake at all, and that most non-trivial cross-platform Qt based projects supporting VS maintain a real .vcproj _in parallel_ to a .pro instead of re-creating it using qmake. In effect, we will be still be talking about a non-too-modest two-digit percentage of Qt users that do neither use qmake nor cmake. [...] I beg to differ. Let's take the example of a buildsystem that is trying to retain source compatibility (thus, we're excluding cmake and, for many things, qmake too [think of QT += widgets print-support]). We can group them in two buckets: A) those that run those tools without absolute paths B) those that run them with absolute paths How do they find the absolute path? The only answer is qmake -query QT_INSTALL_BINS. C) It's hard coded. Having company policies saying All sources have to be on a X:\Project 0815\Sources, and Q:\ is subst'ed to a place with a Qt installation we want you to use today is more common than either of us may wish for... You can't add a third option to a binary choice. Either the paths are absolute or they aren't, there's no other alternative. You are absolutely right. I bow to that impeccable line of argument. However, the mere mortal I am was targeting the The only answer is... part. Using absolute paths does not require running qmake -query QT_INSTALL_BINS. Semantics aside, your option C is part of Bucket B: a specific case of absolute paths where the contents of that path change over time. All the user needs is a Qt version that defaults to prefix Q:\. The only problem I see would be if the layout *under* Q:\ is different from version to version [...] It is not the only the layout, but also the exact name of the files. That is precisely one of the cases where any change in naming, including naming of the libraries, is a needless burden. Note, please, that producing a binary is only part of the development process. There is also deployment/packaging which a few build systems declare out of scope. So some projects _do_ have a couple of scripts on top. And some more _do_ use GUI based tools for deployment, with even less flexibility than scripts, and all will need adjustments as soon as any name changes. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On 24/10/12 04:33, Thiago Macieira wrote: I think we are keeping it simple. The current proposal is the simplest that still works. If you can come up with something even simpler, I'll gladly accept it. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? Drop it. I know I complained about renaming qmake but... it would be simpler to rename qmake to qmake5 than to have a 'special' qmake that may or may not be the qmake that's first in your PATH and that may or may not do something with a -qtx switch. So I'm going to remove my +1 for the 'special' qmake and instead suggest a much simpler solution. This is just for 'qmake' though, everything else... same as it was before. Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build Optional: Create libexec/bin/qmake as a symlink to qmake5 (for Windows... a .bat or .cmd may work, else a copy). The officially supported way to build thus becomes qmake5 and it is guaranteed to work no matter what platform you're on or how you've set your PATH. Yes, we have to update all the documentation. The optional symlink is for complainers like me, so we can continue to run qmake - but only if we set PATH correctly first. It'll also help with old instructions, scripts, etc. that would break if we just renamed qmake ;) -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On terça-feira, 23 de outubro de 2012 21.40.41, Oswald Buddenhagen wrote: The difference is that xmlpatterns, like qdbus and the other applications, can be updated by the Debian alternatives mechanism. yes, debian. have you checked that this is true for all relevant downstreams? The Debian alternatives mechanism gets that name because it came from Debian, not because it exists on Debian only. On OpenSUSE, it comes in a package called update-alternatives. On Fedora, for some reason, it's munged up with chkconfig, but it still exists. I remember it existed on Mandriva too when I used it. -- 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] New proposal for the tool naming
On terça-feira, 23 de outubro de 2012 23.12.58, André Pönitz wrote: Moreover, it is a reasonable assumption that only few Qt based Windows-only projects supporting VS use qmake at all, and that most non-trivial cross-platform Qt based projects supporting VS maintain a real .vcproj in parallel to a .pro instead of re-creating it using qmake. Lars made that argument too when I talked to him. The two problems I see with that are: 1) every time you add a new header or source containing QObject class, you need to modify your non-qmake build settings to moc that file. My (biased) experience from the #qt channel and mailing lists is that people switch back to using qmake to generate the .vcproj after hitting this problem once or twice. I say biased because it's clearly so: people who know how to solve the problem don't come asking for help. The VSAddin case notwithstanding because I'm hoping that we can update it to find the proper moc in $QTDIR/lib/qt5/libexec instead of $QTDIR/bin. 2) we are renaming the libraries anyway. And we already *had* renamed the libraries on Windows when we changed from QtCore4 to QtCore5 (.dll, .lib). Two conclusions come from this: a) we should update VSAddin to know about Qt 5, since it clearly differs b) manual buildsystems will require manual changes anyway, so updating the path to moc is not too much to ask. Also, because of (b), the case of QTDIR=Q:\ that changes over time back and forth from Qt 4 to Qt 5 is not realistic. This case cannot exist for one buildsystem that does know about Qt 5 anyway. Either that's two buildsystems or it's one that knows about 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] New proposal for the tool naming
Fine with me, with a comment inline.
++ Eike
On 20 Oct 2012, at 01:16, Thiago Macieira thiago.macie...@intel.com wrote:
Starting a new thread with some ideas based on the outcomes of the
discussion.
Many thanks to rittk, Simon, Lars and André who helped come up with this.
Note: this applies to the *tools* only. The library naming and installation
paths for plugins and QML files has remained uncontested so far, so we appear
to have a consensus.
The proposal:
1) we introduce a $libexecdir configuration option to qmake and QLibraryInfo.
For backwards compatibility, this $libexecdir will receive the legacy names
of
QT_INSTALL_BINS and QLibraryInfo::BinariesPath. It will default to
$prefix/libexec/qt5, which some distros will change to
$prefix/lib/qt5/libexec.
This directory is *not* expected to be in $PATH on any system and therefore
the documentation cannot assume it is.
In this directory, we'll install the tools not usually run by the user, tools
that are often run by other tools. They will keep their current names. These
tools are:
qmake
moc
rcc
uic
qdbusxml2cpp
qdbuscpp2xml
lconvert
lrelease
lupdate
qml*
qhelpgenerator
qhelpconverter
qcollectiongenerator
qdoc
2) the $bindir, defaulting to $prefix/bin, will now be found by qmake
property
QT_INSTALL_APPS and QLibraryInfo::ApplicationsPath. It contains end-user
applications that retain backwards compatibility of purpose as well as
output.
Those applications are:
qdbus
qdbusviewer
designer
assistant
linguist
qglinfo
pixeltool
[creator]
I'm open to suggestions on whether some of the tools should be symlinked here
(e.g., qmlscene5 - $libexecdir/qmlscene).
3) In addition, we'll create a *new* tool also called qmake that will be
installed to $bindir. This tool shall have the following behaviours:
a) under most circumstances, it will simply find another qmake and pass
through all arguments. That is:
qmake -project
basically will exec
$someotherpath/qmake -project
b) additionally, it accepts an extra argument (-select), which causes it to
select a different Qt version. For example:
qmake -qt=5 -project
qmake -qt=4.8.4 CONFIG+=debug
etc.
As a shorthand, the option -qtX means -qt=X.
This argument will be stripped from the command-line before calling the real
qmake.
Without this option, it will fall back to a well-known environment variable
(say, QT_SELECT=5). And if that is also missing, it selects some
system-defined
or user-defined default.
c) it adds one extra option: -print-versions, which will list which Qt
versions are known to this tool
It is our intention that this new tool replace all pre-existing qmake found
in $PATH. One tool to rule them all.
Creator can query this tool to find all
known Qt versions and populate its listing.
That sounds like a good thing to have, yes.
In turn, the official Qt 5 documentation should always talk about qmake like
so:
qmake -qt5 LIBS+=-L/usr/local/lib -lmysqlclient_r mysql.pro
Just as a side note, that requires that Windows and Mac to also have this tool,
and e.g. on Windows to have that tool in the PATH and pointing to the
corresponding Qt for the environment set up shell scripts. In the SDK, the
tools/ directory might be a good place for it.
Another option would be to still just write qmake foo.pro in the
documentation and document that one needs to make sure to use Qt5 when reading
the Qt5 documentation… after all, on Windows and Mac, developers also manage to
figure out how to call qmake.
This allows the Troll qset function to be implemented like:
function qset() {
local prefix=$(qmake -qt=$1 -query QT_INSTALL_PREFIX)
if [ $? -gt 0 ]; then
echo 2 No such Qt version $1
else
export QT_SELECT=$1
export QTDIR=$prefix
local libdir=$(qmake -query QT_INSTALL_LIBS)
export
LD_LIBRARY_PATH=$libdir${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH)
export PKG_CONFIG_PATH=$libdir/pkgconfig:$PKG_CONFIG_PATH
# optional:
#PATH=$(qmake -query QT_INSTALL_BINS):$PATH
fi
}
function qcd() { cd $QTDIR; }
Additionally, this tool may support options like -add-qt and -set-default-qt.
I'm also open to adding an option -run-tool= (e.g., qmake -qt=5 -run-
tool=qmlplugindump) if that's of interest to people.
I haven't decided whether this tool should be a shell script, a perl script
or
another bootstrapped executable.
Please comment.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
Re: [Development] New proposal for the tool naming
20.10.2012, 03:16, Thiago Macieira thiago.macie...@intel.com: b) additionally, it accepts an extra argument (-select), which causes it to select a different Qt version. For example: qmake -qt=5 -project qmake -qt=4.8.4 CONFIG+=debug I like this idea. Among other benefits, it makes it simpler to create 3rd-party versions of tools, e.g. clang-based moc. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On Friday, October 19, 2012 04:16:14 PM Thiago Macieira wrote:
Starting a new thread with some ideas based on the outcomes of the
discussion. Many thanks to rittk, Simon, Lars and André who helped come up
with this.
(and Tor Arne!)
Note: this applies to the *tools* only. The library naming and installation
paths for plugins and QML files has remained uncontested so far, so we
appear to have a consensus.
In all fairness, I think Ossi still disagrees here.
I personally agree though and I'm very glad to see that we're progressing
nicely in this rather tough topic :)
The proposal:
1) we introduce a $libexecdir configuration option to qmake and
QLibraryInfo. For backwards compatibility, this $libexecdir will receive
the legacy names of QT_INSTALL_BINS and QLibraryInfo::BinariesPath. It will
default to $prefix/libexec/qt5, which some distros will change to
$prefix/lib/qt5/libexec.
This directory is *not* expected to be in $PATH on any system and therefore
the documentation cannot assume it is.
In this directory, we'll install the tools not usually run by the user,
tools that are often run by other tools. They will keep their current
names. These tools are:
qmake
moc
rcc
uic
qdbusxml2cpp
qdbuscpp2xml
lconvert
lrelease
lupdate
qml*
qhelpgenerator
qhelpconverter
qcollectiongenerator
qdoc
2) the $bindir, defaulting to $prefix/bin, will now be found by qmake
property QT_INSTALL_APPS and QLibraryInfo::ApplicationsPath. It contains
end-user applications that retain backwards compatibility of purpose as
well as output. Those applications are:
qdbus
qdbusviewer
designer
assistant
linguist
qglinfo
pixeltool
[creator]
I'm open to suggestions on whether some of the tools should be symlinked
here (e.g., qmlscene5 - $libexecdir/qmlscene).
I like (1) and (2).
3) In addition, we'll create a *new* tool also called qmake that will be
installed to $bindir. This tool shall have the following behaviours:
a) under most circumstances, it will simply find another qmake and pass
through all arguments. That is:
qmake -project
basically will exec
$someotherpath/qmake -project
b) additionally, it accepts an extra argument (-select), which causes it to
select a different Qt version. For example:
qmake -qt=5 -project
qmake -qt=4.8.4 CONFIG+=debug
etc.
As a shorthand, the option -qtX means -qt=X.
This argument will be stripped from the command-line before calling the
real qmake.
Without this option, it will fall back to a well-known environment variable
(say, QT_SELECT=5). And if that is also missing, it selects some
system-defined or user-defined default.
c) it adds one extra option: -print-versions, which will list which Qt
versions are known to this tool
It is our intention that this new tool replace all pre-existing qmake found
in $PATH. One tool to rule them all. Creator can query this tool to find
all known Qt versions and populate its listing.
Sounds like a good idea to turn things around the way you suggest, that Qt
Creator queries this tool instead of the tool using Qt Creator's database.
Qt Creator could perhaps even being migrating over to that db.
In turn, the official Qt 5 documentation should always talk about qmake
like so:
qmake -qt5 LIBS+=-L/usr/local/lib -lmysqlclient_r mysql.pro
This allows the Troll qset function to be implemented like:
function qset() {
local prefix=$(qmake -qt=$1 -query QT_INSTALL_PREFIX)
if [ $? -gt 0 ]; then
echo 2 No such Qt version $1
else
export QT_SELECT=$1
export QTDIR=$prefix
local libdir=$(qmake -query QT_INSTALL_LIBS)
export
LD_LIBRARY_PATH=$libdir${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH)
export PKG_CONFIG_PATH=$libdir/pkgconfig:$PKG_CONFIG_PATH
# optional:
#PATH=$(qmake -query QT_INSTALL_BINS):$PATH
fi
}
function qcd() { cd $QTDIR; }
Additionally, this tool may support options like -add-qt and
-set-default-qt. I'm also open to adding an option -run-tool= (e.g., qmake
-qt=5 -run- tool=qmlplugindump) if that's of interest to people.
It would be lovely it it supported registration, because then the postinst
scripts of distro qt packages could call it to _register_ Qt versions.
I haven't decided whether this tool should be a shell script, a perl script
or another bootstrapped executable.
I'm inclined to suggest a bootstrapped executable. If it had a shell sourcing
mode like dbus-launch, then a separate qset program can be implemented as a
batch file on Windows (that can set environment variables) or as a shell
function on Unixy platforms.
Simon
___
Development mailing list
Development@qt-project.org
Re: [Development] New proposal for the tool naming
The more I read the various related threads, the more I think if qt-project is to do anything it should be to define to LSB/FHS how to configure Qt. I don't necessarily see consensus; but I do see a lot of questions that have gone unanswered. There seems to be a lot of objection to user tool name changes, for the sole benefit of only a portion of the community while having an adverse impact on the (perhaps) larger section of the community. 1. Qt should be installed to a self-contained directory, much like SDK and self-compile users. So Distributions should be discouraged from installing tools directly to /usr/bin, etc. For example, install it all to /usr/share/qt5.0.0 just like the SDK. 2. Distributions should be encouraged to user their existing tooling to enable users to easily switch between different versions of Qt that the distribution supports; perhaps with support for users to register their own custom installs as well. This would be responsible for managing symlinks of all the user/developer visible tools that the distribution wants to put in the public paths (e.g. /usr/bin). This is very distribution specific - e.g. Gentoo would likely use their eselect tool much like they do for python, gcc, default editors and an host of other tools; while other distros would use tooling of their own style that meets their distribution needs in ways that are consistent with their distribution. This would alleviate any need for qt-project to resolve the issue, while showing distributions how it ought to be done. So instead of renaming tools, let's set a standard for how to install Qt in LSB/FHS; one that can apply to more than Qt if LSB/FHS desires it. Any Unix system could adopt the same kind of standard set by LSB/FHS as a guideline as well. Personally, I think renaming things is probably the wrong way to go about solving this issue as numerous tools and environments have qmake and other tools/libraries coded that will need updated - some obviously, some not so obviously. For whatever it may be worth, $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On segunda-feira, 22 de outubro de 2012 10.59.58, Ziller Eike wrote: In turn, the official Qt 5 documentation should always talk about qmake like so: qmake -qt5 LIBS+=-L/usr/local/lib -lmysqlclient_r mysql.pro Just as a side note, that requires that Windows and Mac to also have this tool, and e.g. on Windows to have that tool in the PATH and pointing to the corresponding Qt for the environment set up shell scripts. In the SDK, the tools/ directory might be a good place for it. It's easy to add a -qt5 ignored option to the regular qmake too. -- 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] New proposal for the tool naming
On segunda-feira, 22 de outubro de 2012 15.19.57, Simon Hausmann wrote: I haven't decided whether this tool should be a shell script, a perl script or another bootstrapped executable. I'm inclined to suggest a bootstrapped executable. If it had a shell sourcing mode like dbus-launch, then a separate qset program can be implemented as a batch file on Windows (that can set environment variables) or as a shell function on Unixy platforms. The qset or qt function is up to you. I don't want to go there. Not yet, anyway. As for the choice of language, the big deal is whether I can keep this tool in the qtbase package. I need to hear from distros here. -- 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] New proposal for the tool naming
On Monday, October 22, 2012 07:50:37 AM Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 15.19.57, Simon Hausmann wrote: I haven't decided whether this tool should be a shell script, a perl script or another bootstrapped executable. I'm inclined to suggest a bootstrapped executable. If it had a shell sourcing mode like dbus-launch, then a separate qset program can be implemented as a batch file on Windows (that can set environment variables) or as a shell function on Unixy platforms. The qset or qt function is up to you. I don't want to go there. Not yet, anyway. Right, that's beyond the scope of this thread :) Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On 22 Oct 2012, at 16:47, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 22 de outubro de 2012 10.59.58, Ziller Eike wrote: In turn, the official Qt 5 documentation should always talk about qmake like so: qmake -qt5 LIBS+=-L/usr/local/lib -lmysqlclient_r mysql.pro Just as a side note, that requires that Windows and Mac to also have this tool, and e.g. on Windows to have that tool in the PATH and pointing to the corresponding Qt for the environment set up shell scripts. In the SDK, the tools/ directory might be a good place for it. It's easy to add a -qt5 ignored option to the regular qmake too. So that if you happen to have a real qmake instead of the wrapper in the PATH on linux, you don't realize that when you are doing qmake -qt5 to force most current qt5 version (or whatever the semantics would be), you actually execute a completely different qmake? I don't think that would be a good idea. -- 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] New proposal for the tool naming
22.10.2012, 18:49, Thiago Macieira thiago.macie...@intel.com: On segunda-feira, 22 de outubro de 2012 15.41.19, Konstantin Tokarev wrote: 20.10.2012, 03:16, Thiago Macieira thiago.macie...@intel.com: b) additionally, it accepts an extra argument (-select), which causes it to select a different Qt version. For example: qmake -qt=5 -project qmake -qt=4.8.4 CONFIG+=debug I like this idea. Among other benefits, it makes it simpler to create 3rd-party versions of tools, e.g. clang-based moc. I'm glad you like and I'm glad that it helps improving tools in the future! I just have no idea how one thing relates to the other. Can you share a little more about how this solves a problem that you were seeing? It provides a sane way of coexisting for 2 moc executables for the same Qt version. E.g. someone can register different moc executable for some Qt version and it will work immediately with old makefiles. Otherwise the only option is to overwrite existing moc with no fallback possibility. It also makes possible to have one moc working for several Qt versions. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On segunda-feira, 22 de outubro de 2012 14.59.09, Ziller Eike wrote: Just as a side note, that requires that Windows and Mac to also have this tool, and e.g. on Windows to have that tool in the PATH and pointing to the corresponding Qt for the environment set up shell scripts. In the SDK, the tools/ directory might be a good place for it. It's easy to add a -qt5 ignored option to the regular qmake too. So that if you happen to have a real qmake instead of the wrapper in the PATH on linux, you don't realize that when you are doing qmake -qt5 to force most current qt5 version (or whatever the semantics would be), you actually execute a completely different qmake? I don't think that would be a good idea. It will do that too if it's in a separate build looking at a non-standard configuration path. That's mostly what's going to happen on Windows anyway, isn't it? -- 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] New proposal for the tool naming
On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald Buddenhagen wrote: On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote: Note: this applies to the *tools* only. The library naming and installation paths for plugins and QML files has remained uncontested so far, so we appear to have a consensus. only if you conveniently ignore my two (or three?) mails saying the exact opposite. the problem with renaming the libraries is the same as with tools: project files not based on qmake need to be adjusted. Indeed, but I contest that those changes are minor, expected and understandable. The vast majority of the users are probably using either qmake or cmake (99%?) and those are taken care of already. the bottom line being nobody cares. hey, wait, why change anything at all then? ;) anyway, the actual argument against doing it is that if we don't do the invasive tool renaming, the library renaming is pointless (because it doesn't help). and if we do something similar to the current proposal ... the renaming is pointless (because the inc+lib paths can be found with qmake). all binaries should be in one directory as far as QLibraryInfo (and thus qmake) is concerned. everything else will just again be a PITA for non-distro users. also, it's all documented tools. nothing libexec about it. but that's just a name. I beg to differ. Let's take the example of a buildsystem that is trying to retain source compatibility (thus, we're excluding cmake and, for many things, qmake too [think of QT += widgets print-support]). We can group them in two buckets: A) those that run those tools without absolute paths B) those that run them with absolute paths How do they find the absolute path? The only answer is qmake -query QT_INSTALL_BINS. Since my proposal keeps that compatibility, those buildsystems are not broken. This includes Creator's translation rules, for example. And I contend that the Bucket A is already broken without user intervention. For Bucket A to work, the user must set the PATH to point to where the tools are. Either the user does this manually and will adapt anyway to a new installation, or the user has a script that she will again adapt. Since adaptation is necessary, adding the libexec path to PATH is no big deal. so ... given that one of the cases is broken anyway and needs *some* fix, what's the use of complicating the layout in an attempt to decouple the case that needs no fixing anyway? :} 3) In addition, we'll create a *new* tool also called qmake that will be installed to $bindir. This tool shall have the following behaviours: if you call it qmake, then you should wrap all other binaries as well (as we have established, lupdate blurs the line, and the gui tools will be renamed by some distros no matter how much you disagree with that). Easy to do with qmake -run-tool=lupdate and using argv[0] as a shorthand. that asymmetry is ugly. that tool should be named just qt (or similar) and *all* actual qt binaries should be reachable only via the option or symlink. a separate tool which is used as a wrapper will not work - it's just utterly cumbersome, and we cannot retroactively adjust the documentation anyway. Why is it cumbersome? i meant a qt tool without the symlink trick. you totally don't want to update all documentation to say qt qmake, etc., and as a user i positively don't want to type that. anyway, the bottom line is: this is an entirely separate tool/-set, and qt should stay unmodified. Yes and no: it's an entirely separate tool, except that it might need to be bootstrapped. That would require it live in qtbase.git. we don't actually need bootstrapping, only static linking. anyway, using qt may be advisable if we use a config file based registry. that's one of the reasons why i suggested that maybe we shouldn't. but then, ini file and registry access (if even wanted) are pretty trivial to write in plain c (look at kdm's inifile.c ...). Qt will need to be modified so that the *applications* like qdbus, qdbusviewer, designer, assistant and linguist know where /usr/bin is. why should the apps need to know that? also, it's a non-question when all executables live in one directory. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On segunda-feira, 22 de outubro de 2012 19.23.23, Oswald Buddenhagen wrote: only if you conveniently ignore my two (or three?) mails saying the exact opposite. the problem with renaming the libraries is the same as with tools: project files not based on qmake need to be adjusted. Indeed, but I contest that those changes are minor, expected and understandable. The vast majority of the users are probably using either qmake or cmake (99%?) and those are taken care of already. the bottom line being nobody cares. hey, wait, why change anything at all then? ;) Because of the portion of the 99% that *does* use qmake and needs to find it. anyway, the actual argument against doing it is that if we don't do the invasive tool renaming, the library renaming is pointless (because it doesn't help). and if we do something similar to the current proposal ... the renaming is pointless (because the inc+lib paths can be found with qmake). Except if you want the .so files in /usr/lib co-installable with the Qt 4 ones. Yeah, we could put them in /usr/lib/qt5/lib, but that sounds rather convoluted to me. It also introduces multiarch issues, since then we need one qmake per arch, instead of the solution we have now. I want the Qt prefix to be /usr, not /usr/lib/qt5. How do they find the absolute path? The only answer is qmake -query QT_INSTALL_BINS. Since my proposal keeps that compatibility, those buildsystems are not broken. This includes Creator's translation rules, for example. And I contend that the Bucket A is already broken without user intervention. For Bucket A to work, the user must set the PATH to point to where the tools are. Either the user does this manually and will adapt anyway to a new installation, or the user has a script that she will again adapt. Since adaptation is necessary, adding the libexec path to PATH is no big deal. so ... given that one of the cases is broken anyway and needs *some* fix, what's the use of complicating the layout in an attempt to decouple the case that needs no fixing anyway? :} Exactly. That case that is broken needs attention and its solution is separate from this discussion. I can't fix what's *already* broken due to the Qt 3 and Qt 4 mess. I can only fix going *forward* for Qt 5. installed to $bindir. This tool shall have the following behaviours: if you call it qmake, then you should wrap all other binaries as well (as we have established, lupdate blurs the line, and the gui tools will be renamed by some distros no matter how much you disagree with that). Easy to do with qmake -run-tool=lupdate and using argv[0] as a shorthand. that asymmetry is ugly. that tool should be named just qt (or similar) and *all* actual qt binaries should be reachable only via the option or symlink. That is acceptable too. I can call the tool anything and symlink qmake to it (except on Windows where it will be an actual copy). Symlinking the other tools is optional and should not be the default. Buildsystems need to find the other tools in libexec via full path and not depend on $PATH. i meant a qt tool without the symlink trick. you totally don't want to update all documentation to say qt qmake, etc., and as a user i positively don't want to type that. I do want to update all the documentation to say qmake -qt5. anyway, the bottom line is: this is an entirely separate tool/-set, and qt should stay unmodified. Yes and no: it's an entirely separate tool, except that it might need to be bootstrapped. That would require it live in qtbase.git. we don't actually need bootstrapping, only static linking. True, but you're splitting hairs. The static QtCore library in the regular build is called libbootstrap.a. anyway, using qt may be advisable if we use a config file based registry. that's one of the reasons why i suggested that maybe we shouldn't. but then, ini file and registry access (if even wanted) are pretty trivial to write in plain c (look at kdm's inifile.c ...). I was planning on simple multiple-file reading. One file per Qt version it knows. It's a lot simpler and more package-friendly. Qt will need to be modified so that the *applications* like qdbus, qdbusviewer, designer, assistant and linguist know where /usr/bin is. why should the apps need to know that? also, it's a non-question when all executables live in one directory. Rephrasing: qdbus.pro needs to know where to put its output. Since it's not $$[QT_INSTALL_BINS], we need another path. But you're right that we don't need the change to QLibraryInfo. If anyone ever needs to find and run those tools (not counting their unit tests), QProcess is enough since it will search $PATH. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part.
Re: [Development] New proposal for the tool naming
On Mon, Oct 22, 2012 at 11:19:17AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 19.23.23, Oswald Buddenhagen wrote: only if you conveniently ignore my two (or three?) mails saying the exact opposite. the problem with renaming the libraries is the same as with tools: project files not based on qmake need to be adjusted. Indeed, but I contest that those changes are minor, expected and understandable. The vast majority of the users are probably using either qmake or cmake (99%?) and those are taken care of already. the bottom line being nobody cares. hey, wait, why change anything at all then? ;) Because of the portion of the 99% that *does* use qmake and needs to find it. yes. qmake will say /usr/lib/i386-linux-gnu/qt5/lib, where the unversioned symlink can live witout conflicts. anyway, the actual argument against doing it is that if we don't do the invasive tool renaming, the library renaming is pointless (because it doesn't help). and if we do something similar to the current proposal ... the renaming is pointless (because the inc+lib paths can be found with qmake). Except if you want the .so files in /usr/lib co-installable with the Qt 4 ones. Yeah, we could put them in /usr/lib/qt5/lib, but that sounds rather convoluted to me. It also introduces multiarch issues, since then we need one qmake per arch, instead of the solution we have now. you need a solution for that anyway, because both qconfig.pri and qmodule.pri make qmake arch-specific. I want the Qt prefix to be /usr, not /usr/lib/qt5. well, i don't. How do they find the absolute path? The only answer is qmake -query QT_INSTALL_BINS. Since my proposal keeps that compatibility, those buildsystems are not broken. This includes Creator's translation rules, for example. And I contend that the Bucket A is already broken without user intervention. For Bucket A to work, the user must set the PATH to point to where the tools are. Either the user does this manually and will adapt anyway to a new installation, or the user has a script that she will again adapt. Since adaptation is necessary, adding the libexec path to PATH is no big deal. so ... given that one of the cases is broken anyway and needs *some* fix, what's the use of complicating the layout in an attempt to decouple the case that needs no fixing anyway? :} Exactly. That case that is broken needs attention and its solution is separate from this discussion. I can't fix what's *already* broken due to the Qt 3 and Qt 4 mess. I can only fix going *forward* for Qt 5. i fail to see your argument here. what exactly is the reason why having the apps and the tools in the same bindir would be bad? that asymmetry is ugly. that tool should be named just qt (or similar) and *all* actual qt binaries should be reachable only via the option or symlink. That is acceptable too. I can call the tool anything and symlink qmake to it (except on Windows where it will be an actual copy). there is historically little point in providing convenience links on windows, because everyone uses PATH-based setups anyway. so the tool would be only a qt registry manager (for creator). but anyway. Symlinking the other tools is optional and should not be the default. as i said three times already, lupdate is usefully user-invokable, and the gui tools will be renamed by some distros anyway - so it is only reasonable to isolate and include them into the aliasing magic - always, to avoid fragmentation. i meant a qt tool without the symlink trick. you totally don't want to update all documentation to say qt qmake, etc., and as a user i positively don't want to type that. I do want to update all the documentation to say qmake -qt5. well, i'm pretty sure you didn't *really* think about that. otherwise i'd have to declare you insane. (all the documentation is a tad more than a few qdoc files). ;) anyway, the bottom line is: this is an entirely separate tool/-set, and qt should stay unmodified. Yes and no: it's an entirely separate tool, except that it might need to be bootstrapped. That would require it live in qtbase.git. we don't actually need bootstrapping, only static linking. True, but you're splitting hairs. The static QtCore library in the regular build is called libbootstrap.a. the difference is that your interpretation forces the tool into qtbase (unless i make the bootstrap library available separately, which is well an option), while my interpretation makes only a regular static build a precondition of building the tool independently. anyway, using qt may be advisable if we use a config file based registry. that's one of the reasons why i suggested that maybe we shouldn't. but then, ini file and registry access (if even wanted) are pretty trivial to write in plain c (look at kdm's inifile.c ...). I was
Re: [Development] New proposal for the tool naming
On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald Buddenhagen wrote: On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote: Note: this applies to the *tools* only. The library naming and installation paths for plugins and QML files has remained uncontested so far, so we appear to have a consensus. only if you conveniently ignore my two (or three?) mails saying the exact opposite. the problem with renaming the libraries is the same as with tools: project files not based on qmake need to be adjusted. Indeed, but I contest that those changes are minor, expected and understandable. The vast majority of the users are probably using either qmake or cmake (99%?) and those are taken care of already. That would leave Visual Studio at less than 1%, which is certainly not in sync with any survey I've seen during the last ten years. I beg to differ. Let's take the example of a buildsystem that is trying to retain source compatibility (thus, we're excluding cmake and, for many things, qmake too [think of QT += widgets print-support]). We can group them in two buckets: A) those that run those tools without absolute paths B) those that run them with absolute paths How do they find the absolute path? The only answer is qmake -query QT_INSTALL_BINS. C) It's hard coded. Having company policies saying All sources have to be on a X:\Project 0815\Sources, and Q:\ is subst'ed to a place with a Qt installation we want you to use today is more common than either of us may wish for... Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On segunda-feira, 22 de outubro de 2012 21.21.17, André Pönitz wrote: On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald Buddenhagen wrote: On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote: Note: this applies to the *tools* only. The library naming and installation paths for plugins and QML files has remained uncontested so far, so we appear to have a consensus. only if you conveniently ignore my two (or three?) mails saying the exact opposite. the problem with renaming the libraries is the same as with tools: project files not based on qmake need to be adjusted. Indeed, but I contest that those changes are minor, expected and understandable. The vast majority of the users are probably using either qmake or cmake (99%?) and those are taken care of already. That would leave Visual Studio at less than 1%, which is certainly not in sync with any survey I've seen during the last ten years. I must confess I have no idea how many people are using Visual Studio today and I must also admit I have not a clue about how the add-in or qmake- generated .vcproj files work. But I can make one qualified assumption: if you can start Visual Studio from outside the Qt prompt, then those .vcproj files and the add-in must work -- somehow -- without depending on $PATH. That means they either hardcode a path or they find it somewhere in the registry. My guess is both: qmake hardcodes the paths in the .vcproj it generates and the add-in finds Qt through the registry. That would put them in Bucket B in my list. I beg to differ. Let's take the example of a buildsystem that is trying to retain source compatibility (thus, we're excluding cmake and, for many things, qmake too [think of QT += widgets print-support]). We can group them in two buckets: A) those that run those tools without absolute paths B) those that run them with absolute paths How do they find the absolute path? The only answer is qmake -query QT_INSTALL_BINS. C) It's hard coded. Having company policies saying All sources have to be on a X:\Project 0815\Sources, and Q:\ is subst'ed to a place with a Qt installation we want you to use today is more common than either of us may wish for... You can't add a third option to a binary choice. Either the paths are absolute or they aren't, there's no other alternative. Semantics aside, your option C is part of Bucket B: a specific case of absolute paths where the contents of that path change over time. All the user needs is a Qt version that defaults to prefix Q:\. The only problem I see would be if the layout *under* Q:\ is different from version to version, but that's why we have all those -*dir options to configure. -- 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] New proposal for the tool naming
On segunda-feira, 22 de outubro de 2012 20.52.49, Oswald Buddenhagen wrote: I can't fix what's already broken due to the Qt 3 and Qt 4 mess. I can only fix going forward for Qt 5. i fail to see your argument here. what exactly is the reason why having the apps and the tools in the same bindir would be bad? Because qdbus should be in /usr/bin but the version- and arch-specific qmake should be somewhere in /usr/lib*/qt5. Symlinking the other tools is optional and should not be the default. as i said three times already, lupdate is usefully user-invokable, and the gui tools will be renamed by some distros anyway - so it is only reasonable to isolate and include them into the aliasing magic - always, to avoid fragmentation. So we provide symlinks for a few of the tools in addition to qmake, but I don't see why moc should be in $PATH. The number of people who actually run it manually must be countable in one hand. On the other hand (the one not counting people), applications like qdbus or xmlpatterns make no sense to have in duplication. i meant a qt tool without the symlink trick. you totally don't want to update all documentation to say qt qmake, etc., and as a user i positively don't want to type that. I do want to update all the documentation to say qmake -qt5. well, i'm pretty sure you didn't really think about that. otherwise i'd have to declare you insane. (all the documentation is a tad more than a few qdoc files). Yes, I really meant it. We have to start somewhere. we don't actually need bootstrapping, only static linking. True, but you're splitting hairs. The static QtCore library in the regular build is called libbootstrap.a. the difference is that your interpretation forces the tool into qtbase (unless i make the bootstrap library available separately, which is well an option), while my interpretation makes only a regular static build a precondition of building the tool independently. I would prefer to have the tool inside qtbase, so I can use the libbootstrap.a that is there. Having it outside qtbase means I have the following options: 1) write it with non-Qt code, options of which include shell and perl scripting 2) require a static Qt package to be present, which creates a cyclic dependency link since this tool needs to be present too in order to compile Qt5-based code. No, since this tool is the entry point for building Qt5-based applications, it must either come with Qt or not depend upon it. I was planning on simple multiple-file reading. One file per Qt version it knows. It's a lot simpler and more package-friendly. that makes sense for the system-provided qts (though as i wrote before, this can be deduced based on filesystem policy without any additional information). for user-defined qt versions you need to write something to ~/.config/QtProject/qtversions* anyway - whether it's a single file or multiple doesn't make that much of a difference. Indeed, it doesn't make much of a difference. So I'll just do the easiest, which is to make the reading code simpler. -- 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] New proposal for the tool naming
On Saturday, October 20, 2012 09:10:05 Thiago Macieira wrote: On sábado, 20 de outubro de 2012 10.28.35, Stephen Kelly wrote: On Saturday, October 20, 2012 10:30:36 Alberto Mardegan wrote: On 10/20/2012 02:16 AM, Thiago Macieira wrote: [...] 3) In addition, we'll create a *new* tool also called qmake that will be I wonder how FindQt4.cmake will react to that. If that module finds Qt 5 it is supposed to keep looking for Qt 4. I'm not sure how it would react to qmake suddenly being a perl script instead of qmake.exe for example. The idea is that Linux distributions will make this tool default to Qt 4. So if the user does nothing, FindQt4.cmake will continue working. Yes, I'd imagine so, but haven't thought very deeply about it. Why not use a tool of a new name? Why overload the meaning and responsiblity of qmake? Because everyone is complaining of having a new name. Yes, I was a bit confused between what you wrote and what Alberto wrote about storing settings. People were complaining about a new name for qmake. I still think a separate tool (eg qset) is a better idea than a new tool with the same name as an existing one. If the new tool is to be installed to /usr/bin/qmake and the Qt 4 qmake is today at /usr/bin/qmake, packagers have to change everything in their Qt 4 packages or they will conflict and not be coinstallable. I thought that was the main reason for this whole thing. If you covered that in your initial email, I missed it. As you seem to hint in the follow-up e-mail, this is not limited to version numbers, but can contain toolchain information: qmake -qt=5 qmake -qt=5-mingw32 qmake -qt=4.8-maemo5 Right? If so, that would be excellent. ... but only useful for Qt, not for the whole environment. I have a bash function called qt (and a similar one called kde) which lets me choose an environment where Qt is my focus, but not the limit to what I want access to. That is, I also want my cmake to find the correct Qt, which means setting the CMAKE_PREFIX_PATH environment variable. Yeah, to be honest I'll probably keep my own shell function too. I still need to set the source directory for my shadow builds and it might not be easy to find it with qmake variables. But if it works, I'll replace mine. Right, so we're agreed that for us and for everyone else who has their own solution already, your proposal solves nothing. The easiest way to achieve that is probably to create a solution based on files and you create a ~/.config/qconfig-maemo5 which shadows the one in /etc/qconfig-maemo5 and adds what you want. (Assuming the -add-qt option described below would be implemented to find files like that, but you get the idea). Do you want to store more settings in the config file? Ok... I can consider that a feature request. I'm not sure what you mean by settings, but I'd guess that your I don't really want anything from your new tool proposal, except for it to 'stay out of my way'. Your proposal doesn't have any benefit for me and what I do with Qt. I, like many others have wrappers similar to qset. Just to review who *is* supposed to benefit from this: * Not Windows or Mac users. They are already managed by the user * Not SDK users on Linux * Not people who download binary libraries from qt-project * Not people who compile (and therefore choose the prefix of) their own Qt * Yes - people who use distro -dev(el)? packages to develop against Qt. * Yes - people who do user support on #qt, interest@, forums etc. * Newbies finding 3rd party documentation with consistent tool names. Have I missed any? I get the impression that most people developing against Qt, even on Linux, are using the SDK. I imagine that the bulk of the people using -devel packages are KDE people, who are tied to the Qt version that KDE depends on, so I don't think they'll benefit from the tool changes you propose. I'm sure there are some other people who use distro -devel packages for their Qt based development, but they can't debug into Qt AFAIK, so they're already not having a good experience and should use the SDK or self-compile instead. Regarding user support and newbies, I'm not sure your proposal helps the scenario Sune mentioned: http://thread.gmane.org/gmane.comp.lib.qt.devel/7258/focuss16 depending on what you have set as your default you can maybe write qmake, maybe you need to either switch the default to qt5 or alternatively write qmake -qt=5 to build things The more I think about this renaming, the fewer people I think will be positively affected by it. What I'd really like to see is a list of trade-offs, or two lists of trade- offs. One list of trade offs for doing no renamings, and one list for your renaming proposal. I'd like to see that on a wiki so that it's a live document we can update as the proposals and arguments keep flowing, and I'd like to see it present all sides and Qt-users affected. I'm sure it would
Re: [Development] New proposal for the tool naming
Why not use a tool of a new name? Why overload the meaning and responsiblity of qmake? snip If the new tool is to be installed to /usr/bin/qmake and the Qt 4 qmake is today at /usr/bin/qmake, packagers have to change everything in their Qt 4 packages or they will conflict and not be coinstallable. I thought that was the main reason for this whole thing. If you covered that in your initial email, I missed it. The packagers have to change the only Qt4 qmake's name/path and register the existing installation(s) to be known to that new qmake wrapper, nothing more. The easiest way to achieve that is probably to create a solution based on files and you create a ~/.config/qconfig-maemo5 which shadows the one in /etc/qconfig-maemo5 and adds what you want. (Assuming the -add-qt option described below would be implemented to find files like that, but you get the idea). snip Just to review who *is* supposed to benefit from this: * Not Windows or Mac users. They are already managed by the user Qt users on Widnows could use such qmake to manage their Qt installations. Have no clue about the Mac users, though. My proposition was to not install this new qmake wrapper by default iff libexecdir equals to bindir - so the old behavior could be achieved easily. * Not SDK users on Linux * Not people who download binary libraries from qt-project * Not people who compile (and therefore choose the prefix of) their own Qt An arbitrary Qt installation/build can be registered (just like Kits in Creator). * Yes - people who use distro -dev(el)? packages to develop against Qt. * Yes - people who do user support on #qt, interest@, forums etc. * Newbies finding 3rd party documentation with consistent tool names. Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On Sun 21 Oct 2012 05:40:13 Stephen Kelly escribió: [snip] I get the impression that most people developing against Qt, even on Linux, are using the SDK. Well, my impression is exactly the contrary: most people developing against Qt just install the development packages. In fact, I have never met someone who installed the SDK when [s]he can get the packages from the distro repo. Kinds regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ 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] New proposal for the tool naming
On Sun, Oct 21, 2012 at 2:45 PM, Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: Well, my impression is exactly the contrary: most people developing against Qt just install the development packages. In fact, I have never met someone who installed the SDK when [s]he can get the packages from the distro repo. Commercial users usually get the SDK, especially if they are redistributing Qt along with the application ($ORIGIN rpath / LD_LIBRARY_PATH, etc) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On Sunday, October 21, 2012 12:56:05 Konstantin Ritt wrote: Why not use a tool of a new name? Why overload the meaning and responsiblity of qmake? snip If the new tool is to be installed to /usr/bin/qmake and the Qt 4 qmake is today at /usr/bin/qmake, packagers have to change everything in their Qt 4 packages or they will conflict and not be coinstallable. I thought that was the main reason for this whole thing. If you covered that in your initial email, I missed it. The packagers have to change the only Qt4 qmake's name/path and The whole point of this proposal used to be to make it not necessary for distros to patch Qt. This proposal as you state is requires everyone to patch Qt 4 even more (Right?). This is exactly why this point should have been part of the initial proposal: If we don't care about distros patching Qt 4 anymore - only Qt 5 - that is a particular goal, but I haven't seen it stated like that anywhere. I didn't know that was the goal in particular of this new proposal. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ** Qt Developer Conference: http://qtconference.kdab.com/ ** 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] New proposal for the tool naming
On Sunday, October 21, 2012 09:45:57 you wrote: On Sun 21 Oct 2012 05:40:13 Stephen Kelly escribió: [snip] I get the impression that most people developing against Qt, even on Linux, are using the SDK. Well, my impression is exactly the contrary: most people developing against Qt just install the development packages. It depends whether they are targetting a particular Qt version (choose the SDK or a tarball of binaries, no matter what the distros provide. We use Qt 4.6.2 because all later versions have 'bugs' and our app doesn't work) or targetting the distro (The program must work on Ubuntu 12.04 and Fedora 14). Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ** Qt Developer Conference: http://qtconference.kdab.com/ ** 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] New proposal for the tool naming
On Sunday, October 21, 2012 09:32:33 Thiago Macieira wrote: On domingo, 21 de outubro de 2012 18.06.46, Stephen Kelly wrote: The packagers have to change the only Qt4 qmake's name/path and The whole point of this proposal used to be to make it not necessary for distros to patch Qt. This proposal as you state is requires everyone to patch Qt 4 even more (Right?). Not even more. Most distributions configure Qt 4 like so: --prefix=/usr/lib/qt4 --bindir=/usr/bin And in addition symlink, copy or rename qmake to qmake-qt4. So they already patch Qt. What I'm asking is that they patch *less* now: - configure Qt without --bindir - drop a new file in a known location (/etc/xdg/qmake/qt4.conf) - let the new qmake wrapper in /usr/bin/qmake I see. If such a wrapper exists, then: * It will need to be in a separate package from the Qt 4 and Qt 5 repos * It needs to be maintained and released on its own cycle as needed ** Supported features of conf files will no doubt need to be expanded * It needs to be compatibile with all Qt 4 and all future Qt versions forever * Distros will need to make both Qt 4 and Qt 5 packages depend on it ** Therefore it can't be implemented in Qt * It will never become obsolete All correct? Did I miss anything? This is exactly why this point should have been part of the initial proposal: If we don't care about distros patching Qt 4 anymore - only Qt 5 - that is a particular goal, but I haven't seen it stated like that anywhere. I didn't know that was the goal in particular of this new proposal. This new proposal requires adaptations to the Qt 4 packages, indeed. Could you update the proposal to be more clear on that then? Preferably on a wiki. Preferably also list goals and non goals. For example Sune's concern that I linked to before seems to have become a non-goal. Please make those things explicit. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ** Qt Developer Conference: http://qtconference.kdab.com/ ** 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] New proposal for the tool naming
On domingo, 21 de outubro de 2012 19.06.32, Stephen Kelly wrote: I see. If such a wrapper exists, then: * It will need to be in a separate package from the Qt 4 and Qt 5 repos * It needs to be maintained and released on its own cycle as needed ** Supported features of conf files will no doubt need to be expanded * It needs to be compatibile with all Qt 4 and all future Qt versions forever * Distros will need to make both Qt 4 and Qt 5 packages depend on it ** Therefore it can't be implemented in Qt * It will never become obsolete All correct? Did I miss anything? More or less. I was thinking it might work if it's inside the qtbase sources. If distros are going to provide Qt 5, they need to compile qtbase anyway. The only thing we need is to provide a way for the wrapper from qt5 to be suppressed if the qt6 one is being installed. Providing it outside of Qt 4 or 5 means I need to write it in shell or Perl. This new proposal requires adaptations to the Qt 4 packages, indeed. Could you update the proposal to be more clear on that then? Preferably on a wiki. Later, when I know what those requirements are. I'm waiting for packagers and others to comment on the proposal. Preferably also list goals and non goals. For example Sune's concern that I linked to before seems to have become a non-goal. Please make those things explicit. What concern? -- 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] New proposal for the tool naming
On Sunday, October 21, 2012 10:51:12 Thiago Macieira wrote: All correct? Did I miss anything? More or less. I was thinking it might work if it's inside the qtbase sources. If distros are going to provide Qt 5, they need to compile qtbase anyway. The only thing we need is to provide a way for the wrapper from qt5 to be suppressed if the qt6 one is being installed. Something for packagers to chime in on. Preferably also list goals and non goals. For example Sune's concern that I linked to before seems to have become a non-goal. Please make those things explicit. What concern? See my mail from this morning in reply to you. It relates to user support. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ** Qt Developer Conference: http://qtconference.kdab.com/ ** 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] New proposal for the tool naming
Serves me right for not reading _all_ the mail in this folder before replying to an old thread... On 20/10/12 09:16, Thiago Macieira wrote: a) under most circumstances, it will simply find another qmake and pass through all arguments. That is: qmake -project basically will exec $someotherpath/qmake -project +1 b) additionally, it accepts an extra argument (-select), which causes it to select a different Qt version. For example: qmake -qt=5 -project qmake -qt=4.8.4 CONFIG+=debug etc. As a shorthand, the option -qtX means -qt=X. This argument will be stripped from the command-line before calling the real qmake. Without this option, it will fall back to a well-known environment variable (say, QT_SELECT=5). And if that is also missing, it selects some system-defined or user-defined default. +1 Though, I'm not sure we need QT_SELECT. If you can change an environment variable, you can modify PATH. It is our intention that this new tool replace all pre-existing qmake found in $PATH. One tool to rule them all. Creator can query this tool to find all known Qt versions and populate its listing. +1 Additionally, this tool may support options like -add-qt and -set-default-qt. I'm also open to adding an option -run-tool= (e.g., qmake -qt=5 -run- tool=qmlplugindump) if that's of interest to people. I guess -add-qt is more for developer convenience? Under normal operation, I'd expect distros to install Qt + /etc/xdg/qmake/something.conf for this tool to find. I suppose set-default-qt is necessarily user-specific. I'm going to respond here to people asking for directory-specific qmake binding: Just set PATH. Setup a cdrc thing in your shell if you want to automate this. I haven't decided whether this tool should be a shell script, a perl script or another bootstrapped executable. If this replaces the Qt 4 qmake, it might be problematic to have it built from Qt 5 sources. It would need to be statically built and split off during packaging so that it had no dependencies on Qt 5. If you can achieve that, go ahead and write it in Qt. -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On segunda-feira, 22 de outubro de 2012 13.57.36, Lincoln Ramsay wrote: Though, I'm not sure we need QT_SELECT. If you can change an environment variable, you can modify PATH. Changing one variable to a specific value is considerably easier than changing PATH. Additionally, this tool may support options like -add-qt and -set-default-qt. I'm also open to adding an option -run-tool= (e.g., qmake -qt=5 -run- tool=qmlplugindump) if that's of interest to people. This can also be used for symlinking if it detects argv[0]. I guess -add-qt is more for developer convenience? Under normal operation, I'd expect distros to install Qt + /etc/xdg/qmake/something.conf for this tool to find. Yes. I suppose set-default-qt is necessarily user-specific. Yes. I'm going to respond here to people asking for directory-specific qmake binding: Just set PATH. Setup a cdrc thing in your shell if you want to automate this. As I said, modifying PATH isn't easy and it can have adverse consequences. But it is an option available to you. I haven't decided whether this tool should be a shell script, a perl script or another bootstrapped executable. If this replaces the Qt 4 qmake, it might be problematic to have it built from Qt 5 sources. It would need to be statically built and split off during packaging so that it had no dependencies on Qt 5. If you can achieve that, go ahead and write it in Qt. Yup. -- 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] New proposal for the tool naming
On 10/20/2012 02:16 AM, Thiago Macieira wrote: [...] 3) In addition, we'll create a *new* tool also called qmake that will be installed to $bindir. This tool shall have the following behaviours: a) under most circumstances, it will simply find another qmake and pass through all arguments. That is: qmake -project basically will exec $someotherpath/qmake -project b) additionally, it accepts an extra argument (-select), which causes it to select a different Qt version. For example: qmake -qt=5 -project qmake -qt=4.8.4 CONFIG+=debug etc. [...] As you seem to hint in the follow-up e-mail, this is not limited to version numbers, but can contain toolchain information: qmake -qt=5 qmake -qt=5-mingw32 qmake -qt=4.8-maemo5 Right? If so, that would be excellent. [...] Additionally, this tool may support options like -add-qt and -set-default-qt. I'm also open to adding an option -run-tool= (e.g., qmake -qt=5 -run- tool=qmlplugindump) if that's of interest to people. If you are open to feature requests, here's another one: -store (or any better name) which stores the value of the -qt= option into $PWD/.qmake-config which the qmake wrapper will use as default configuration when run from this directory with no -qt argument. That would allow one to do: cd ~/src/projectA qmake -qt=5 -store [...] cd ../projectB qmake -qt=5-mingw32 -store And from that time on one doesn't need to remember what qt version or toolchain one has to use for a project, and just always type qmake from the project base directory. Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On 10/20/2012 11:28 AM, Stephen Kelly wrote: And from that time on one doesn't need to remember what qt version or toolchain one has to use for a project, and just always type qmake from the project base directory. This is the right goal imo, but the wrong implementation. I'm not sure that we have the same goal -- or at least, I didn't understand from your explanation how to achieve it. What I want to be able to do is: # some steps to configure the projects as desired, # and from that time on be able to do $ cd src/projectA $ qmake # uses qmake for qt5 $ cd ../projectB $ qmake # uses qmake for qt4 Without any intermediate steps to select the version (which I might not remember). In order to be able to make this, you need to have a specialized qmake program which decides which qmake binary to run. Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On Saturday, October 20, 2012 12:12:39 Alberto Mardegan wrote: On 10/20/2012 11:28 AM, Stephen Kelly wrote: And from that time on one doesn't need to remember what qt version or toolchain one has to use for a project, and just always type qmake from the project base directory. This is the right goal imo, but the wrong implementation. I'm not sure that we have the same goal -- or at least, I didn't understand from your explanation how to achieve it. What I want to be able to do is: # some steps to configure the projects as desired, # and from that time on be able to do $ cd src/projectA $ qmake # uses qmake for qt5 $ cd ../projectB $ qmake # uses qmake for qt4 Without any intermediate steps to select the version (which I might not remember). In order to be able to make this, you need to have a specialized qmake program which decides which qmake binary to run. Indeed. I missed your goal of the tool figuring out whether to use the Qt 4 or Qt 5 qmake *without* any intermediate steps (presumably you want that stored in $PWD and to apply to all subdirectories when qmake -store is run?). I'm not sure I like that idea, but I guess I could just not use the feature. Regarding remembering, that's also a problem that most people have solved for themselves I'm sure. My shell prompt looks like this: Qt( ) KDE ( ) stephen@hal:~/dev/src$ qt 5 Qt( 5 ) KDE ( ) stephen@hal:~/dev/src$ qt 48 Qt( 4.8 ) KDE ( ) stephen@hal:~/dev/src$ qt 47 Qt( 4.7 ) KDE ( ) stephen@hal:~/dev/src$ qt undef Qt( ) KDE ( ) stephen@hal:~/dev/src$ qt 48 Qt( 4.8 ) KDE ( ) stephen@hal:~/dev/src$ kde 47 Qt( 4.8 ) KDE ( 4.7 ) stephen@hal:~/dev/src$ qt 47 Qt( 4.7 ) KDE ( 4.7 ) stephen@hal:~/dev/src$ So I can't *not* remember. It's right there. Anyway, even if the tool would 'store' the information about which qmake to run, my point about that not being the complete environment still stands. Maybe you can replace 'cd' with a wrapper script? :) Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ** Qt Developer Conference: http://qtconference.kdab.com/ ** 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] New proposal for the tool naming
On sábado, 20 de outubro de 2012 10.28.35, Stephen Kelly wrote: On Saturday, October 20, 2012 10:30:36 Alberto Mardegan wrote: On 10/20/2012 02:16 AM, Thiago Macieira wrote: [...] 3) In addition, we'll create a *new* tool also called qmake that will be I wonder how FindQt4.cmake will react to that. If that module finds Qt 5 it is supposed to keep looking for Qt 4. I'm not sure how it would react to qmake suddenly being a perl script instead of qmake.exe for example. The idea is that Linux distributions will make this tool default to Qt 4. So if the user does nothing, FindQt4.cmake will continue working. If the user does something to select Qt 5, that is the user's fault. It's equivalent to setting today's qmake first in $PATH. Why not use a tool of a new name? Why overload the meaning and responsiblity of qmake? Because everyone is complaining of having a new name. As you seem to hint in the follow-up e-mail, this is not limited to version numbers, but can contain toolchain information: qmake -qt=5 qmake -qt=5-mingw32 qmake -qt=4.8-maemo5 Right? If so, that would be excellent. ... but only useful for Qt, not for the whole environment. I have a bash function called qt (and a similar one called kde) which lets me choose an environment where Qt is my focus, but not the limit to what I want access to. That is, I also want my cmake to find the correct Qt, which means setting the CMAKE_PREFIX_PATH environment variable. Yeah, to be honest I'll probably keep my own shell function too. I still need to set the source directory for my shadow builds and it might not be easy to find it with qmake variables. But if it works, I'll replace mine. My whole point here is that developers don't use only qmake, and qmake isn't the only tool that should do different things when a different Qt is desired. You'll want a different toolchain and tools and everything. True, but many of those settings can be found by inferring from qmake. If it doesn't work, then yeah, get the from somewhere else. The easiest way to achieve that is probably to create a solution based on files and you create a ~/.config/qconfig-maemo5 which shadows the one in /etc/qconfig-maemo5 and adds what you want. (Assuming the -add-qt option described below would be implemented to find files like that, but you get the idea). Do you want to store more settings in the config file? Ok... I can consider that a feature request. Therefore, developers will still need to write their own tools which set environment variables (as you can see, I implemented my own tool similar to qset). I don't think there's any point in 'solving' the problem only for finding Qt, and not for the supporting required tools. Oh, yeah, this is based on setting an environment variable. A tool can't set an environment variable, you need to write your own wrapper. -- 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] New proposal for the tool naming
FWIW, +1 - with one modification - reflect at least the minor version in the
install path - so $prefix/libexec/qt5.0, if not $prefix/libexec/qt5.0.0.
I think there is probably a simple rule we could maintain: Keeping the names of
developer visible tools the same is, IHMO, a must. Tools that are not developer
visible, but called through generated build environments (e.g. Makefiles
generated by Qmake) can be changed.
$0.02
Ben
- Original Message -
From: Thiago Macieira thiago.macie...@intel.com
To: development@qt-project.org
Cc:
Sent: Friday, October 19, 2012 7:16 PM
Subject: [Development] New proposal for the tool naming
Starting a new thread with some ideas based on the outcomes of the
discussion.
Many thanks to rittk, Simon, Lars and André who helped come up with this.
Note: this applies to the *tools* only. The library naming and installation
paths for plugins and QML files has remained uncontested so far, so we appear
to have a consensus.
The proposal:
1) we introduce a $libexecdir configuration option to qmake and QLibraryInfo.
For backwards compatibility, this $libexecdir will receive the legacy names
of
QT_INSTALL_BINS and QLibraryInfo::BinariesPath. It will default to
$prefix/libexec/qt5, which some distros will change to
$prefix/lib/qt5/libexec.
This directory is *not* expected to be in $PATH on any system and therefore
the documentation cannot assume it is.
In this directory, we'll install the tools not usually run by the user,
tools
that are often run by other tools. They will keep their current names. These
tools are:
qmake
moc
rcc
uic
qdbusxml2cpp
qdbuscpp2xml
lconvert
lrelease
lupdate
qml*
qhelpgenerator
qhelpconverter
qcollectiongenerator
qdoc
2) the $bindir, defaulting to $prefix/bin, will now be found by qmake
property
QT_INSTALL_APPS and QLibraryInfo::ApplicationsPath. It contains end-user
applications that retain backwards compatibility of purpose as well as
output.
Those applications are:
qdbus
qdbusviewer
designer
assistant
linguist
qglinfo
pixeltool
[creator]
I'm open to suggestions on whether some of the tools should be symlinked
here
(e.g., qmlscene5 - $libexecdir/qmlscene).
3) In addition, we'll create a *new* tool also called qmake that will be
installed to $bindir. This tool shall have the following behaviours:
a) under most circumstances, it will simply find another qmake and pass
through all arguments. That is:
qmake -project
basically will exec
$someotherpath/qmake -project
b) additionally, it accepts an extra argument (-select), which causes it to
select a different Qt version. For example:
qmake -qt=5 -project
qmake -qt=4.8.4 CONFIG+=debug
etc.
As a shorthand, the option -qtX means -qt=X.
This argument will be stripped from the command-line before calling the real
qmake.
Without this option, it will fall back to a well-known environment variable
(say, QT_SELECT=5). And if that is also missing, it selects some
system-defined
or user-defined default.
c) it adds one extra option: -print-versions, which will list which Qt
versions are known to this tool
It is our intention that this new tool replace all pre-existing qmake found
in $PATH. One tool to rule them all. Creator can query this tool to find all
known Qt versions and populate its listing.
In turn, the official Qt 5 documentation should always talk about qmake like
so:
qmake -qt5 LIBS+=-L/usr/local/lib -lmysqlclient_r mysql.pro
This allows the Troll qset function to be implemented like:
function qset() {
local prefix=$(qmake -qt=$1 -query QT_INSTALL_PREFIX)
if [ $? -gt 0 ]; then
echo 2 No such Qt version $1
else
export QT_SELECT=$1
export QTDIR=$prefix
local libdir=$(qmake -query QT_INSTALL_LIBS)
export LD_LIBRARY_PATH=$libdir${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH)
export PKG_CONFIG_PATH=$libdir/pkgconfig:$PKG_CONFIG_PATH
# optional:
#PATH=$(qmake -query QT_INSTALL_BINS):$PATH
fi
}
function qcd() { cd $QTDIR; }
Additionally, this tool may support options like -add-qt and -set-default-qt.
I'm also open to adding an option -run-tool= (e.g., qmake -qt=5 -run-
tool=qmlplugindump) if that's of interest to people.
I haven't decided whether this tool should be a shell script, a perl script
or
another bootstrapped executable.
Please comment.
--
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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org
[Development] New proposal for the tool naming
Starting a new thread with some ideas based on the outcomes of the discussion.
Many thanks to rittk, Simon, Lars and André who helped come up with this.
Note: this applies to the *tools* only. The library naming and installation
paths for plugins and QML files has remained uncontested so far, so we appear
to have a consensus.
The proposal:
1) we introduce a $libexecdir configuration option to qmake and QLibraryInfo.
For backwards compatibility, this $libexecdir will receive the legacy names of
QT_INSTALL_BINS and QLibraryInfo::BinariesPath. It will default to
$prefix/libexec/qt5, which some distros will change to $prefix/lib/qt5/libexec.
This directory is *not* expected to be in $PATH on any system and therefore
the documentation cannot assume it is.
In this directory, we'll install the tools not usually run by the user, tools
that are often run by other tools. They will keep their current names. These
tools are:
qmake
moc
rcc
uic
qdbusxml2cpp
qdbuscpp2xml
lconvert
lrelease
lupdate
qml*
qhelpgenerator
qhelpconverter
qcollectiongenerator
qdoc
2) the $bindir, defaulting to $prefix/bin, will now be found by qmake property
QT_INSTALL_APPS and QLibraryInfo::ApplicationsPath. It contains end-user
applications that retain backwards compatibility of purpose as well as output.
Those applications are:
qdbus
qdbusviewer
designer
assistant
linguist
qglinfo
pixeltool
[creator]
I'm open to suggestions on whether some of the tools should be symlinked here
(e.g., qmlscene5 - $libexecdir/qmlscene).
3) In addition, we'll create a *new* tool also called qmake that will be
installed to $bindir. This tool shall have the following behaviours:
a) under most circumstances, it will simply find another qmake and pass
through all arguments. That is:
qmake -project
basically will exec
$someotherpath/qmake -project
b) additionally, it accepts an extra argument (-select), which causes it to
select a different Qt version. For example:
qmake -qt=5 -project
qmake -qt=4.8.4 CONFIG+Þbug
etc.
As a shorthand, the option -qtX means -qt=X.
This argument will be stripped from the command-line before calling the real
qmake.
Without this option, it will fall back to a well-known environment variable
(say, QT_SELECT=5). And if that is also missing, it selects some system-defined
or user-defined default.
c) it adds one extra option: -print-versions, which will list which Qt
versions are known to this tool
It is our intention that this new tool replace all pre-existing qmake found
in $PATH. One tool to rule them all. Creator can query this tool to find all
known Qt versions and populate its listing.
In turn, the official Qt 5 documentation should always talk about qmake like
so:
qmake -qt5 LIBS+=-L/usr/local/lib -lmysqlclient_r mysql.pro
This allows the Troll qset function to be implemented like:
function qset() {
local prefix=$(qmake -qt=$1 -query QT_INSTALL_PREFIX)
if [ $? -gt 0 ]; then
echo 2 No such Qt version $1
else
export QT_SELECT=$1
export QTDIR=$prefix
local libdir=$(qmake -query QT_INSTALL_LIBS)
export
LD_LIBRARY_PATH=$libdir${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH)
export PKG_CONFIG_PATH=$libdir/pkgconfig:$PKG_CONFIG_PATH
# optional:
#PATH=$(qmake -query QT_INSTALL_BINS):$PATH
fi
}
function qcd() { cd $QTDIR; }
Additionally, this tool may support options like -add-qt and -set-default-qt.
I'm also open to adding an option -run-tool= (e.g., qmake -qt=5 -run-
tool=qmlplugindump) if that's of interest to people.
I haven't decided whether this tool should be a shell script, a perl script or
another bootstrapped executable.
Please comment.
--
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] New proposal for the tool naming
On Sat, Oct 20, 2012 at 1:16 AM, Thiago Macieira thiago.macie...@intel.comwrote: b) additionally, it accepts an extra argument (-select), which causes it to select a different Qt version. For example: qmake -qt=5 -project qmake -qt=4.8.4 CONFIG+=debug etc. As a shorthand, the option -qtX means -qt=X. This argument will be stripped from the command-line before calling the real qmake. Without this option, it will fall back to a well-known environment variable (say, QT_SELECT=5). And if that is also missing, it selects some system-defined or user-defined default. [..] In turn, the official Qt 5 documentation should always talk about qmake like so: qmake -qt5 LIBS+=-L/usr/local/lib -lmysqlclient_r mysql.pro What's -qt5 ? Latest Qt 5.x.y available? A shorthand for qmake -qt=5.0.0? Something else? Also, why not use pkg-config --list-all and simply look for everything called libqt-x.y.z or alike? (I know, I know, no external dependencies is an advantage and this new qmake is very easy to implement but still...) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On sábado, 20 de outubro de 2012 01.31.18, Pau Garcia i Quiles wrote: What's -qt5 ? Latest Qt 5.x.y available? A shorthand for qmake -qt=5.0.0? Something else? The latest available or some pre-configured alias. I was hoping to leave that part for later, until I implement this tool. My current idea is to have this tool backed by multiple files, stored in /etc/xdg/qmake and ~/.config/qmake. Therefore, the 5 version might be a symlink to another file. This also allows distributions to install and remove multiple Qt versions by just dropping the file in or taking it out. Also, why not use pkg-config --list-all and simply look for everything called libqt-x.y.z or alike? (I know, I know, no external dependencies is an advantage and this new qmake is very easy to implement but still...) Because: a) I don't want to depend on pkg-config b) that's not what pkg-config was designed for c) that requires installing one more .pc file, in addition to the ones we have d) the location of this pkg-config install is most likely *different* from $libdir/pkgconfig. -- 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] New proposal for the tool naming
On sexta-feira, 19 de outubro de 2012 16.16.14, Thiago Macieira wrote: 1) we introduce a $libexecdir configuration option to qmake and QLibraryInfo. For backwards compatibility, this $libexecdir will receive the legacy names of QT_INSTALL_BINS and QLibraryInfo::BinariesPath. It will default to $prefix/libexec/qt5, which some distros will change to $prefix/lib/qt5/libexec. Change of idea: this should default to $libdir/qt5/libexec and Linux distros are under strict recommendations *not* to change it. Why? Because this directory contains tools that are arch-dependent. The 64-bit qmlplugindump cannot be used with 32-bit plugins. Unless distros have a suggestion for how to deal with this. -- 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
