<div class="gmail_quote">On Wed, Aug 3, 2011 at 10:50 AM, Sascha Zelzer <span dir="ltr"><<a href="mailto:s.zelzer@dkfz-heidelberg.de">s.zelzer@dkfz-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<u></u>

  
    
  
  <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 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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; "><b><pre style="display: inline !important; ">

Undefined interface</pre></b></span>). Would Visual Studio handle that as well ?</div><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>Julien.</div></div>