[Development] New proposal for the tool naming

[Stephen Kelly]

On Saturday, October 20, 2012 09:10:05 Thiago Macieira wrote:
> On sábado, 20 de outubro de 2012 10.28.35, Stephen Kelly wrote:
> > On Saturday, October 20, 2012 10:30:36 Alberto Mardegan wrote:
> > > On 10/20/2012 02:16 AM, Thiago Macieira wrote:
> > > [...]
> > > 
> > > > 3) In addition, we'll create a *new* tool also called qmake that will
> > > > be
> > 
> > I wonder how FindQt4.cmake will react to that. If that module finds Qt 5
> > it
> > is supposed to keep looking for Qt 4. I'm not sure how it would react to
> > qmake suddenly being a perl script instead of qmake.exe for example.
> 
> The idea is that Linux distributions will make this tool default to Qt 4. So
> if the user does nothing, FindQt4.cmake will continue working.

Yes, I'd imagine so, but haven't thought very deeply about it.

> > Why not use a tool of a new name? Why overload the meaning and
> > responsiblity of qmake?
> 
> Because everyone is complaining of having a new name.

Yes, I was a bit confused between what you wrote and what Alberto wrote about 
storing settings. People were complaining about a new name for qmake.

I still think a separate tool (eg qset) is a better idea than a new tool with 
the same name as an existing one. 

If the new tool is to be installed to /usr/bin/qmake and the Qt 4 qmake is 
today at /usr/bin/qmake, packagers have to change everything in their Qt 4 
packages or they will conflict and not be coinstallable. I thought that was 
the main reason for this whole thing. If you covered that in your initial 
email, I missed it.

> > > As you seem to hint in the follow-up e-mail, this is not limited to
> > > 
> > > version numbers, but can contain toolchain information:
> > >   qmake -qt=5
> > >   qmake -qt=5-mingw32
> > >   qmake -qt=4.8-maemo5
> > > 
> > > Right? If so, that would be excellent.
> > 
> > ... but only useful for Qt, not for the whole environment. I have a bash
> > function called qt (and a similar one called kde) which lets me choose an
> > environment where Qt is my focus, but not the limit to what I want access
> > to. That is, I also want my cmake to find the correct Qt, which means
> > setting the CMAKE_PREFIX_PATH environment variable.
> 
> Yeah, to be honest I'll probably keep my own shell function too. I still
> need to set the source directory for my shadow builds and it might not be
> easy to find it with qmake variables. But if it works, I'll replace mine.

Right, so we're agreed that for us and for everyone else who has their own 
solution already, your proposal solves nothing.

> 
> > The easiest way to achieve that is probably to create a solution based on
> > files and you create a ~/.config/qconfig-maemo5 which shadows the one in
> > /etc/qconfig-maemo5 and adds what you want. (Assuming the -add-qt option
> > described below would be implemented to find files like that, but you get
> > the idea).
> 
> Do you want to store more settings in the config file? Ok... I can consider
> that a feature request.

I'm not sure what you mean by settings, but I'd guess that your 

I don't really want anything from your new tool proposal, except for it to 
'stay out of my way'. Your proposal doesn't have any benefit for me and what I 
do with Qt. I, like many others have wrappers similar to qset.

Just to review who *is* supposed to benefit from this:
* Not Windows or Mac users. They are already managed by the user
* Not SDK users on Linux
* Not people who download binary libraries from qt-project
* Not people who compile (and therefore choose the prefix of) their own Qt
* Yes - people who use distro -dev(el)? packages to develop against Qt.
* Yes - people who do user support on #qt, interest@, forums etc.
* Newbies finding 3rd party documentation with consistent tool names.

Have I missed any?

I get the impression that most people developing against Qt, even on Linux, 
are using the SDK.

I imagine that the bulk of the people using -devel packages are KDE people, 
who are tied to the Qt version that KDE depends on, so I don't think they'll 
benefit from the tool changes you propose. I'm sure there are some other 
people who use distro -devel packages for their Qt based development, but they 
can't debug into Qt AFAIK, so they're already not having a good experience and 
should use the SDK or self-compile instead.

Regarding user support and newbies, I'm not sure your proposal helps the 
scenario Sune mentioned:

http://thread.gmane.org/gmane.comp.lib.qt.devel/7258/focus=7316

"depending on what you
have set as your default you can maybe write qmake, maybe you need to
either switch the default to qt5 or alternatively write qmake -qt=5 to 
build things"

The more I think about this renaming, the fewer people I think will be 
positively affected by it.

What I'd really like to see is a list of trade-offs, or two lists of trade-
offs. One list of trade offs for doing no renamings, and one list for your 
renaming proposal. I'd like to see that on a wiki so that it's a live document 
we can update as the proposals and arguments keep flowing, and I'd like to see 
it present all sides and Qt-users affected. 

I'm sure it would be a lot of work, but if this renaming is something that's 
really important (and one of the beta2 blockers), it's a necessary reference 
for people to be able to keep up. I've already lost track of all the trade-
offs and 
counter-arguments that have been brought up in the other large threads. My 
query about /usr/bin/qmake above and what the goal even is anymore is the 
result of me losing track.

Thanks,

-- 
Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
** Qt Developer Conference: http://qtconference.kdab.com/ **
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121021/4c3e6853/attachment.sig>