[Development] New proposal for the tool naming

[André Pönitz]

On Mon, Oct 22, 2012 at 01:46:09PM -0700, Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 21.21.17, André Pönitz wrote:
> > On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote:
> > > On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald
> > > 
> > > Buddenhagen wrote:
> > > > On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote:
> > > > > Note: this applies to the *tools* only. The library naming and
> > > > > installation paths for plugins and QML files has remained
> > > > > uncontested so far, so we appear to have a consensus.
> > > > 
> > > > only if you conveniently ignore my two (or three?) mails saying
> > > > the exact opposite. the problem with renaming the libraries is
> > > > the same as with tools: project files not based on qmake need to
> > > > be adjusted.
> > > 
> > > Indeed, but I contest that those changes are minor, expected and
> > > understandable. The vast majority of the users are probably using
> > > either qmake or cmake (99%?) and those are taken care of already.
> > 
> > That would leave Visual Studio at less than 1%, which is certainly
> > not in sync with any survey I've seen during the last ten years.
> 
> I must confess I have no idea how many people are using Visual Studio
> today and I must also admit I have not a clue about how the add-in or
> qmake- generated .vcproj files work.

I'll try to find a number tomorrow. Until then simply assume we are
talking about not-to-modest two-digit percentages.

Moreover, it is a reasonable assumption that only few Qt based
Windows-only projects supporting VS use qmake at all, and that most
non-trivial cross-platform Qt based projects supporting VS maintain a
"real" .vcproj _in parallel_ to a .pro instead of re-creating it 
using qmake.

In effect, we will be still be talking about a non-too-modest two-digit
percentage of Qt users that do neither use qmake nor cmake.
 
> [...]
> > > I beg to differ. Let's take the example of a buildsystem that is
> > > trying to retain source compatibility (thus, we're excluding cmake
> > > and, for many things, qmake too [think of QT += widgets
> > > print-support]). We can group them in two buckets:
> > > 
> > > A) those that run those tools without absolute paths B) those that
> > > run them with absolute paths
> > > 
> > > How do they find the absolute path? The only answer is "qmake
> > > -query QT_INSTALL_BINS".
> > 
> > C) It's hard coded. Having company policies saying "All sources have
> > to be on a X:\Project 0815\Sources, and Q:\ is subst'ed to a place
> > with a Qt installation we want you to use today" is more common than
> > either of us may wish for...
> 
> You can't add a third option to a binary choice. Either the paths are
> absolute or they aren't, there's no other alternative.

You are absolutely right. I bow to that impeccable line of argument.

However, the mere mortal I am was targeting the "The only answer is..."
part. Using absolute paths does not require running "qmake -query
QT_INSTALL_BINS".

> Semantics aside, your option C is part of Bucket B: a specific case of
> absolute paths where the contents of that path change over time. All
> the user needs is a Qt version that defaults to "prefix Q:\". The only
> problem I see would be if the layout *under* Q:\ is different from
> version to version [...]

It is not the only the layout, but also the exact name of the files.
That is precisely one of the cases where any change in naming, including
naming of the libraries, is a needless burden.

Note, please, that producing a binary is only part of the development
process. There is also deployment/packaging which a few build systems
declare "out of scope". So some projects _do_ have "a couple of scripts"
on top. And some more _do_ use GUI based tools for deployment, with even
less flexibility than scripts, and all will need adjustments as soon as
any name changes.

Andre'