[Ctk-developers] org_commontk_dah_app depends on org_commontk_dah_core

[Sascha Zelzer]

On 08/03/2011 05:05 PM, Julien Finet wrote:
> On Wed, Aug 3, 2011 at 10:50 AM, Sascha Zelzer 
> <s.zelzer at dkfz-heidelberg.de <mailto:s.zelzer at dkfz-heidelberg.de>> wrote:
>
>     On 08/03/2011 04:29 PM, Julien Finet wrote:
>>     On Wed, Aug 3, 2011 at 4:07 AM, Sascha Zelzer
>>     <s.zelzer at dkfz-heidelberg.de
>>     <mailto:s.zelzer at dkfz-heidelberg.de>> wrote:
>>
>>         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.'
>>
>>
>>     Do you mean that the dependency is now handled by the order of
>>     add_subdirectory calls ?
>     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 .
>
> Understood:
> the configure-time dependency of the 2 plugins is handled via the 
> order of add_subdirectory calls.
> the build-time  dependency of the 2 plugins is handled 
> via manifest_headers.cmake.
> Makes sense, thanks for the clarification.

Correct.

>     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.
>
>
> 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: *
> Undefined interface
> *). Would Visual Studio handle that as well ?

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.

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

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.

- Sascha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110803/03be3be5/attachment.html>