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