> 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 <[email protected]>: >> From: Thiago Macieira <[email protected]> > >> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
