[Development] New proposal for the tool naming

[Thiago Macieira]

On segunda-feira, 22 de outubro de 2012 20.52.49, Oswald Buddenhagen wrote:
> > I can't fix what's already broken due to the Qt 3 and Qt 4 mess. I can
> > only  fix going forward for Qt 5.
> > 
> 
> i fail to see your argument here. what exactly is the reason why having
> the "apps" and the "tools" in the same bindir would be bad?

Because qdbus should be in /usr/bin but the version- and arch-specific qmake 
should be somewhere in /usr/lib*/qt5.

> > Symlinking the other tools is optional and should not be the default.
> 
> as i said three times already, lupdate is usefully user-invokable, and
> the gui tools will be renamed by some distros anyway - so it is only
> reasonable to isolate and include them into the aliasing magic - always,
> to avoid fragmentation.

So we provide symlinks for a few of the tools in addition to qmake, but I 
don't see why moc should be in $PATH. The number of people who actually run it 
manually must be countable in one hand.

On the other hand (the one not counting people), applications like qdbus or 
xmlpatterns make no sense to have in duplication.

> > > i meant a "qt" tool without the "symlink trick". you totally don't want
> > > to update all documentation to say "qt qmake", etc., and as a user i
> > > positively don't want to type that.
> >
> > I do want to update all the documentation to say "qmake -qt5".
>
> well, i'm pretty sure you didn't really think about that. otherwise
> i'd have to declare you insane. ("all the documentation" is a tad more
> than a few qdoc files).

Yes, I really meant it. We have to start somewhere.

> > > we don't actually need bootstrapping, only static linking.
> >
> > True, but you're splitting hairs. The "static QtCore" library in the
> > regular  build is called "libbootstrap.a".
> 
> the difference is that your interpretation forces the tool into qtbase
> (unless i make the bootstrap library available separately, which is well
> an option), while my interpretation makes only a regular static build a
> precondition of building the tool independently.

I would prefer to have the tool inside qtbase, so I can use the libbootstrap.a 
that is there. Having it outside qtbase means I have the following options:

1) write it with non-Qt code, options of which include shell and perl 
scripting

2) require a static Qt package to be present, which creates a cyclic 
dependency link since this tool needs to be present too in order to compile 
Qt5-based code.

No, since this tool is the entry point for building Qt5-based applications, it 
must either come with Qt or not depend upon it.

> > I was planning on simple multiple-file reading. One file per Qt version
> > it 
> > knows. It's a lot simpler and more package-friendly.
> 
> that makes sense for the system-provided qts (though as i wrote before,
> this can be deduced based on filesystem policy without any additional
> information). for user-defined qt versions you need to write something
> to ~/.config/QtProject/qtversions* anyway - whether it's a single file
> or multiple doesn't make that much of a difference.

Indeed, it doesn't make much of a difference. So I'll just do the easiest, 
which is to make the reading code simpler.

-- 
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/9b591cce/attachment.sig>