[Development] New proposal for the tool naming

[BRM]

> From: Thiago Macieira <thiago.macieira at 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