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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
