[Development] New proposal for the tool naming

[Thiago Macieira]

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.

But I can make one qualified assumption: if you can start Visual Studio from 
outside the Qt prompt, then those .vcproj files and the add-in must work -- 
somehow -- without depending on $PATH. That means they either hardcode a path 
or they find it somewhere in the registry. My guess is both: qmake hardcodes 
the paths in the .vcproj it generates and the add-in finds Qt through the 
registry.

That would put them in Bucket B in my list.

> > 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.

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, but that's why we 
have all those -*dir options to configure.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121022/ab0bfa7f/attachment.sig>