[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Thiago Macieira]

On Sunday 18 January 2015 22:24:15 Kevin Kofler wrote:
> Konstantin Ritt wrote:
> > There is no need for moc/rcc/uic to be suffixed. In fact, they are an
> > internal build tools invoked by qmake and thus they should normally reside
> > in libexec dir (or you may query qmake for its specific libexec dir path
> > to invoke them manually) -- just like GCC's cc1 or fixincl.
> 
> That is just not true. Many Qt programs out there are NOT built using qmake,
> but more flexible build systems. Those build systems need to call those
> tools themselves. Even Qt itself is experimenting with qmake replacements
> (see e.g. QBS). cc1 is almost never invoked directly (only through gcc),
> but this is not true for moc, rcc, uic etc. So hiding them in a non-PATH
> directory is not an ideal solution (even if that directory can be found by
> invoking qmake).

We're not making the point that qmake is the only program that runs those 
tools. We're making the point that the user never runs them directly, 
buildsystems do. And this whole discussion started about qmake, which is how 
you find those tools in the first place.

In 2012, the alternate solution to renaming everything was to put the non-user 
applications in libexec. I also had a patch to that when the renaming was 
declared a non-starter. This proposal was also discarded due to being in the 
losing side of the argument.

Today, a blue-sky proposal, given infinite resources, would be:
 1) qmake works for all Qt versions
 2) there's a tool for Qt's config, separate from qmake (say, qt5-config)
 3) user applications are in $(bindir) and promise to retain compatibility
 4) non-user tools are in $(libexec)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center