<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 08/03/2011 04:29 PM, Julien Finet wrote:
<blockquote
cite="mid:CAKoWPPGMMU1iWnjbiV3+LBJn6ox9_55GogD6JNF_cb4JAdOL+w@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Wed, Aug 3, 2011 at 4:07 AM, Sascha
Zelzer <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:s.zelzer@dkfz-heidelberg.de">s.zelzer@dkfz-heidelberg.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div class="im">For plug-ins, dependencies to other plug-ins
are encoded in the manifest_headers.cmake file (instead of
target_libraries.cmake). This makes the information
available at runtime. The dependencies are already correctly
set-up but the order of the plug-ins in the CMakeLists.txt
did not reflect their dependencies. Multiple CMake configure
runs hid the problem and I fixed it just now.'</div>
</blockquote>
<div><br>
</div>
<div>Do you mean that the dependency is now handled by the order
of add_subdirectory calls ? <br>
</div>
</div>
</blockquote>
Well, the dependencies are still handled via the target_libraries
and additionally for plug-ins via the manifest_headers.cmake files.
However, the order of the add_subdirectory calls is important (both
for Libs and Plug-ins) for automatically figuring out transitive
include directories. A bit simplified, the macros look for a
<plugin-dependency>_SRC_DIR variable which is automatically
set by CMake due to the project(<plugin-dependency>) call in
each plug-in (or lib). If the add_subdirectory order is wrong, those
variables may not exist yet. This was the actual problem:
org_commontk_dah_app was missing a the include directory to
org_commontk_dah_core .<br>
<blockquote
cite="mid:CAKoWPPGMMU1iWnjbiV3+LBJn6ox9_55GogD6JNF_cb4JAdOL+w@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>If I understand correctly, <span class="Apple-style-span"
style="border-collapse: collapse; color: rgb(80, 0, 80);
font-family: arial,sans-serif; font-size: 13px;">org_commontk_dah_app
can only be built if </span><span class="Apple-style-span"
style="border-collapse: collapse; color: rgb(80, 0, 80);
font-family: arial,sans-serif; font-size: 13px;">org_commontk_dah_core
is built (not just configured).</span></div>
<div><font class="Apple-style-span" color="#500050" face="arial,
sans-serif"><span class="Apple-style-span"
style="border-collapse: collapse;">As there is no
direct dependencies between </span></font><span
class="Apple-style-span" style="border-collapse: collapse;
color: rgb(80, 0, 80); font-family: arial,sans-serif;
font-size: 13px;">org_commontk_dah_app and </span><span
class="Apple-style-span" style="border-collapse: collapse;
color: rgb(80, 0, 80); font-family: arial,sans-serif;
font-size: 13px;">org_commontk_dah_core, Visual Studio can
run them in parallel, no ? (and Visual Studio, by default,
build projects in parallel) </span></div>
<div><font class="Apple-style-span" color="#500050" face="arial,
sans-serif"><span class="Apple-style-span"
style="border-collapse: collapse;">So it seems to be prone
to a race condition. Is there something I didn't take into
account ?</span></font></div>
</div>
</blockquote>
org_commontk_dah_app uses classes from org_commontk_dah_core (like
the ctkSimpleSoapServer). It's object files can be built in parallel
to the object files of org_commontk_dah_core, but the linking step
will only take place after the org_commontk_dah_core import library
has been created. Visual Studio takes care of that.<br>
<br>
- Sascha<br>
</body>
</html>