Qt-interest Archive, July 2006
Project dependencies in Visual Studio Solutions (.sln)
Message 1 in thread
We gotten plenty of reports that
TEMPLATE = subdirs
CONFIG += ordered
SUBDIRS += project1 project2 project3 project4
doesn't actually create the correct dependencies for Visual Studio
Solution files. Now, I can reveal that no, it doesn't care about
"ordered".
The Solution generator tries to be smarter, and adds the "correct
dependencies" based on what you link your project with, and what
applications you use in custom build-steps.
This _should_ be enough IMO; and it's definitely enough to build the
whole Qt package (libraries, examples, tools and all) using a
distributed buildsystem for maximum parallelization.
The thing is, CONFIG+=ordered was added as a simple measure to add
order to the chaos of Makefiles and modularized projects. At a later
point, qmake added more complex build dependency syntax for
TEMPLATE=subdirs, but I won't cover that here. Suffice it to say, not
even all of the Qt package uses this advanced dependency system, yet.
So, if qmake was "fixed" so that the Solution generator would follow
this "old" way of ensuring a set build order, we would kill a lot of
the potential parallelization currently available when using
distributed buildsystem. And I doubt that any customer is currently
using the more advanced dependency system in qmake.
Now, there are a couple of precautions you need to be aware of for the
automatic dependency generation to work properly in MS Solution files,
which Daniel Walz mention on the 12th of June here on Qt-Interest:
The dependencies are generated automatically, if
1a) there is a Lib/DLL project with the target name (the .lib
is used, not the .dll of course) being that of what is
used on link line of an other project in your solution
1b) there is a Exe project with the target name being that of
what is used in a custom build-step of an other project
in your solution
2) you don't use paths in the TARGET variable (use DESTDIR/
DLLDESTDIR for that), like TARGET=$(SOME_VARIABLE)/myLib,
won't work
3) if you have a special location for your libs, you specify
the -Lmy/library/path and LIBS += mylib, instead of just
using LIBS += my/library/path/mylib
4) the leaf projects are created before you generate the
solution file. (You can use the recursive flag for qmake
to do this, like "qmake -tp vc -r [yourproject.pro]"
Maybe the rules 2 and 3 are too strict, but that's how it works
currently anyways.
Back to the issue at hand:
We gotten a few requests to fix the "ordered" issue in the Solution
generator (even if "ordered" isn't even documented in the qmake manual
:-)), and 12 people have voted on the public task #114852 as a
"Significant/Must-have" feature. Now, I think the automated dependency
stuff handles like 99% of the cases for all customers, as long as they
follow the rules above. And as making the solution generator follow
the "ordered" feature would kill performance for all customers using a
distributed buildsystem on Windows, I'm hesitant to make such a
change; even if it would fix the issue for those remaining 1%.
The question is, is the issue so big that it justifies potentially
killing build performance for customers using a distributed
buildsystem? I guess we could make qmake ignore the "CONFIG +=
ordered", but respect the new and more advanced dependency system,
_and_ try to do the automatic dependency generation?
If you have strong feelings and ideas about this issue, please let me
know! Add _your_ vote and comments to the public task
(http://www.trolltech.com/developer/task-tracker/index_html?id=114852&method=entry).
(Voting and commenting in the Task Tracker system is only available
for customers) Or, reply to this post at qt-interest! I'll be
monitoring both closely..
--
[ signature omitted ]
Message 2 in thread
Marius Storm-Olsen <marius_noreply@xxxxxxxxxxxxx> wrote on 07/06/2006
09:22:47 AM:
# And I doubt that any customer is currently using the more
# advanced dependency system in qmake.
Not yet, true, but it appears to be a foregone conclusion that if
QMake has a feature that I will eventually come around to beat the tar
out of it :)
In this case, that time will probably be coming up shortly, as the
project that I am now working on is a large hierarchy of sub-project
libraries, some of which depend on each other - so I can quickly
foresee this becoming an issue for me - depending on how well the
"automagical" one works that is :)
*snip*
# If you have strong feelings and ideas about this issue, please let me
# know! Add _your_ vote and comments to the public task
# (http://www.trolltech.com/developer/task-tracker/index_html?
# id=114852&method=entry).
# (Voting and commenting in the Task Tracker system is only available
# for customers) Or, reply to this post at qt-interest! I'll be
# monitoring both closely..
I don't have any strong feelings yet, but I'll let you know when I get
there?
--
[ signature omitted ]
Message 3 in thread
> # And I doubt that any customer is currently using the more
> # advanced dependency system in qmake.
>
> Not yet, true, but it appears to be a foregone conclusion that if
> QMake has a feature that I will eventually come around to beat the
> tar out of it :)
lol :-)
Yeah, we do have some people out there that seem to put their pride in
twisting the last drop out of qmake.
> In this case, that time will probably be coming up shortly, as the
> project that I am now working on is a large hierarchy of sub-project
> libraries, some of which depend on each other - so I can quickly
> foresee this becoming an issue for me - depending on how well the
> "automagical" one works that is :)
Well, Qt has some pretty complex dependencies too, take the designer
examples:
examples\designer\customwidgetplugin
When using the "automagical", if you will, dependency generator the
project ends up being dependent on:
src\tools\moc
src\corelib\QtCore
src\gui\QtGui
src\xml\QtXml
tools\designer\src\lib\QtDesigner
and for me, using a distributed buildsystem, that example compiles even
before it's started on the designer libs. The when all the dependencies
are built, it's linked.. nifty, huh? :-)
That way, I can flood the build farm, and build _all_ of Qt (libs,
tools, examples) in 10-20min, depending on what else I'm doing and who
else is building.
> *snip*
>
> # If you have strong feelings and ideas about this issue, please let me
> # know! Add _your_ vote and comments to the public task
> # (http://www.trolltech.com/developer/task-tracker/index_html?
> # id=114852&method=entry).
> # (Voting and commenting in the Task Tracker system is only available
> # for customers) Or, reply to this post at qt-interest! I'll be
> # monitoring both closely..
>
> I don't have any strong feelings yet, but I'll let you know when I get
> there?
Oh, and one thing: If you decide to give some really tricky dependency
stuff a go, please try the latest snapshot, as a path issue was fixed
there just recently which could miss some of the dependencies.
--
[ signature omitted ]
