[Development] New proposal for the tool naming

[Konstantin Ritt]

> 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_witness at yahoo.com>:
>> 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
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development