<!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 05:05 PM, Julien Finet wrote:
<blockquote
cite="mid:CAKoWPPGoP=tAK4yT5ms58OGXRCAuMJaTE-oJMJrU1QwGJkfL9w@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Wed, Aug 3, 2011 at 10:50 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 bgcolor="#ffffff" text="#000000">
<div class="im"> On 08/03/2011 04:29 PM, Julien Finet wrote:
<blockquote 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"
target="_blank">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>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>
</div>
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 .</div>
</blockquote>
<div>Understood:</div>
<div>the configure-time dependency of the 2 plugins is handled
via the order of add_subdirectory calls.</div>
<div>the build-time dependency of the 2 plugins is handled
via manifest_headers.cmake.</div>
<div>Makes sense, thanks for the clarification.</div>
</div>
</blockquote>
<br>
Correct.<br>
<br>
<blockquote
cite="mid:CAKoWPPGoP=tAK4yT5ms58OGXRCAuMJaTE-oJMJrU1QwGJkfL9w@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im">
<blockquote type="cite">
<div class="gmail_quote"> </div>
</blockquote>
</div>
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>
</div>
</blockquote>
<div><br>
</div>
<div>Don't we have 2 kind of dependencies here ? At link-ing
time (and I trust you that Visual Studio takes care of it if
we told him so(manifest_headers.cmake)), but there is a prior
dependency, at moc-ing time (so the error: <span
class="Apple-style-span" style="font-family:
Arial,Helvetica,sans-serif; font-size: 14px;"><b>
<pre style="display: inline ! important;">
Undefined interface</pre>
</b></span>). Would Visual Studio handle that as well ?</div>
</div>
</blockquote>
<br>
That error was actually a bit misleading. The C++ parser shipped
with "moc" does not complain if it cannot resolve an #include
<...> statement. Since the include directories were wrong (due
to the wrong configure-time dependency) the header file could not be
included by moc and hence it did not know about the "interface"
declared in that header file.<br>
<br>
<blockquote
cite="mid:CAKoWPPGoP=tAK4yT5ms58OGXRCAuMJaTE-oJMJrU1QwGJkfL9w@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<div>Right now the CMake code for configuring plugins is
directly in CTK/CMakeLists.txt. Wouldn't it make more sense to
have it in CTK/Plugins/CMakeLists.txt (or some other
CMakeLists.txt)?</div>
<div><br>
</div>
</div>
</blockquote>
<br>
We could move the creation of the CMake variable which contains the
list of plug-ins (and libs) to a separate file inside an appropriate
directory. However, this file must still be included in the
top-level CMakeLists.file due to the way the
ctkMacroValidateBuildOptions macro works.<br>
<br>
- Sascha<br>
</body>
</html>