[Development] New proposal for the tool naming

Thiago Macieira thiago.macieira at intel.com
Wed Oct 24 02:04:47 CEST 2012

On terça-feira, 23 de outubro de 2012 23.12.58, André Pönitz wrote:
> 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.

Lars made that argument too when I talked to him.

The two problems I see with that are:

1) every time you add a new header or source containing QObject class, you 
need to modify your non-qmake build settings to moc that file. My (biased) 
experience from the #qt channel and mailing lists is that people switch back 
to using qmake to generate the .vcproj after hitting this problem once or 
twice. I say biased because it's clearly so: people who know how to solve the 
problem don't come asking for help.

The VSAddin case notwithstanding because I'm hoping that we can update it to 
find the proper moc in $QTDIR/lib/qt5/libexec instead of $QTDIR/bin.

2) we are renaming the libraries anyway. And we already *had* renamed the 
libraries on Windows when we changed from QtCore4 to QtCore5 (.dll, .lib). Two 
conclusions come from this:
 a) we should update VSAddin to know about Qt 5, since it clearly differs
 b) manual buildsystems will require manual changes anyway, so updating the 
     path to moc is not too much to ask.

Also, because of (b), the case of QTDIR=Q:\ that changes over time back and 
forth from Qt 4 to Qt 5 is not realistic. This case cannot exist for one 
buildsystem that does know about Qt 5 anyway. Either that's two buildsystems 
or it's one that knows about Qt 5.

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/20121023/2f1a0ffc/attachment.sig>

More information about the Development mailing list