[Development] renaming qmake for everyone (was: Re: Co-installation & library naming rules=)

[Ziller Eike]

Reposting after setting some "plain text" flags in the mail client, in the hope of better readability for Thiago.

On 18.10.2012, at 16:30, BRM wrote:

>> From: Oswald Buddenhagen <oswald.buddenhagen at digia.com>
> 
>> Subject: [Development] renaming qmake for everyone (was: Re: Co-installation & library naming rules=)
>> [changed the subject to get some attention ... from a quick survey i
>> don't have the impression that many people grasp that this thread is
>> very much relevant for them.]
> 
> 
> I had stopped reading the other thread, but this now interests me so its helpful to do so.
> Thanks!
> 
> 
>> On Thu, Oct 11, 2012 at 04:11:10PM -0700, Thiago Macieira wrote:
>>> On quinta-feira, 11 de outubro de 2012 21.16.56, Oswald Buddenhagen wrote:
>>>> On Thu, Oct 11, 2012 at 11:56:44AM -0700, Thiago Macieira wrote:
>>>>> Considering all the changes I am proposing do NOT harm any of the
>>>>> people that build from sources,
>>>> 
>>>> they *do* harm. i positively do *not* want to use qmake-qt5 just because
>>>> it's the least evil for linux package users.
>>> 
>>> That's the very most important change that needs to be done: renaming qmake. 
>>> All the other tools could be separated elsewhere, the libs could be in 
>>> different dirs. But qmake is the one tool run directly by users, the one tool 
>>> that Qt Creator asks users to locate.
>>> 
>>> It needs to be renamed..
>>> 
>>> If you don't want to make it the default, then at the very least we need to 
>>> add the option to our configure script to force the renaming. We need to adapt 
>>> our buildsystem to creating the renamed tool. This is not debatable... we 
>>> simply need to do it in Qt.
>>> 
>>> I don't want distribution packagers choosing different methods: I want them all 
>>> to have the same solution, the one solution that will be recommended to LSB 
>>> 5.0, the one solution that the helpful people in #qt, interest@ and other 
>>> discussion channels will need to know.
>>> 
>>> In other words, the renaming will be the de-facto default for everyone using 
>>> Linux.
>>> 
>>> Why the hell shouldn't it be the de jure default too?
>> 
>> after having seen your first patches and thinking some more about the
>> consequences, i'm more than ever convinced that this initiative is
>> entirely misguided.
>> 
>> the basic point is that you are actively breaking backwards
>> compatibility.
>> before this change, we could simply tell people "change your PATH, qmake
>> && make". heck, we could even tell them "run $qtdir/bin/qmake && make".
>> this is even emphasized by your own initiative to rename quick1 back to
>> declarative.
>> 
>> with this change it gets nasty:
>> - in the easiest case people use qmake, and it covers all their needs.
>>   the one thing they need to remember is using qmake5 instead of qmake -
>>   this is annoying and leads to asymmetries when major versions are not
>>   the only reason for separation (think minor versions and different
>>   build configurations), but it's kinda bearable.
>> - the next case is people using tools which are not covered by qmake.
>>   think lupdate, lrelease, xmlpatterns. this needs adjustment.
>> - the next case is not even using qmake. now everything needs to be
>>   adjusted - all tool and library names.
>> one can argue that this is a one-time change. but reality shows that it
>> isn't for the transition phase during the next months: creator supports
>> both versions, and it's probably not going to be the only such project.
>> so we get lots of conditionals in the project files.
> 
> 
> Here's another example: My projects have build scripts that are very simple so that I can build the dependencies and then the actual project.
> Each of these needs to run 'qmake' and support multiple versions easily. Right now, it's just "qmake", I make sure the right version of qmake is in the path,
> and the build scripts just work across many versions of Qt. Changing the name to "qmake5" by default would break that; and there is no simply solution to
> finding the right version - environmental variables won't help as they would clash too.

Well, the easy solution is to use an alias / symbolic link qmake ---> qmakeX that is in the PATH.
But actually that would be an easy solution to the parallel installation instead of renaming too.
bin/qmake ---> /whereever/5.0.0/qmake
/whereever/5.0.0/qmake
/whereever/5.0.1/qmake

Qt Creator users that want to use the flexible "current qt setting" by using bin/qmake, or can use fixed versions by using /whereever/5.0.0/qmake.

>> now let's look at the problem it solves:
>> - in theory, linux distributors can now use -prefix /usr and don't need
>>   to rename any build-related things on their own, and thus we set the
>>   ultimate standard upstream
>> - in reality, some distributors will still rename linguist and other
>>   "end user tools", as they have "no-conflict" policies, so "everybody
>>   does the same" remains a blue-sky dream.
>> 
>> as you wrote yourself above, distributors can easily put the qt versions
>> in different places (like they do so far), and it doesn't cause much
>> trouble (see my previous mails). however, you are arguing that if
>> nothing else, qmake still needs to be renamed. i think that's just
>> wrong: to not break the path-based setups, it must be only *aliased*,
>> and that happens outside the qt installation directory. therefore it is
>> outside the scope of qt's repositories.
> 
> 
> Agreed.
> 
> On Windows, there isn't really much of an issue - the tools allow one to switch between versions of Qt without a problem; and it's typically difference Command-line Environments setup by the installer that make the changes - though I use the commercial installers.
> 
> On Linux/Mac/Unix though I think there is an elegant solution that distributors can do - use aliases, and provide a script to change between them. Many distributors already do that for tools like editors, compilers, etc. So why not Qt too? The only issue is the solution will typically be distribution specific; but again, its a distributions issue if they want to do the renaming.


I'd throw Mac out of sentences that have Linux in them in this discussion: There are no "Mac" distributions/distributors that package Qt :)

On Mac, Qt will either be self-compiled (you are on your own which is fine), or installed through our binary installers - which will install different Qt versions (version + tool chain specific) into different directories
(http://qt-project.org/wiki/Qt5_beta2_component_tree) so there is no conflict either.
Same situation like on Windows, except that Windows has the environment set up thingies.

Developers who distribute their Qt application on Windows and Mac usually ship a private Qt copy with their application --> no conflict. But even if they install Qt systemwide, we are using frameworks on Mac which automatically do versioning for major versions if done right, and we are adding the major version to dlls on Windows already.

The *only* thing that would be solved is how Linux distributors can install multiple (major) versions of Qt simultaneously.

-- 
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