[CMake] [ryppl-dev] Re: $<> expressions in include_directories command

[Jean-Christophe Fillion-Robin]

We used also a similar approach in CTK.

See http://www.commontk.org/index.php/Documentation/BuildSystem_Descriptionand
also [1] and [2]

Relaying on small executable named DGraph built at configure time, we manage
to obtain the topological order of CTK plugins, apps and libraries. The tool
also check for cycle and output a human readable message if there are any
cycle.

Note also that each library, plugins and app has access to only the include
directories it should.

If I remember properly, Sasha from the German Cancer Research Center
(DKFZ)did some work factorizing out the CMake code so that it could
easily be
re-used.

Sasha> Could you comment ?

Thanks
Jc

[1] http://www.commontk.org/docs/html/group__CMakeAPI.html [2]
http://www.commontk.org/docs/html/group__CMakeUtilities.html

On Mon, Jul 25, 2011 at 1:16 PM, Brad King <brad.king at kitware.com> wrote:

> On 07/25/2011 12:00 PM, Daniel Pfeifer wrote:
> > what is your opinion on the $<> syntax I originally proposed?
> > This would not require creating virtual targets for header only
> libraries.
>
> The implementation is just doing delayed variable evaluation and
> is not a true generator expression in the same sense as is used
> by add_test and add_custom_command.  The latter support only
> generator-defined specific expressions with very specific syntax
> that can be validated.  The FinalPass of commands is an ancient
> implementation detail which exists only in a few commands for
> historical reasons and should not be used in new commands.
>
> The proposed solution is to use delayed evaluation to work around
> lack of dependency-sorted ordering.  The topological sort already
> used by the Boost CMake solves this problem in a better way.  The
> ITK project already does CMake-time module dependency detection
> and sorting using a similar approach.  It correctly handles the
> generation of include directories for each module.  It also handles
> header-only modules.  Unfortunately the implementation is embedded
> in ITK's CMake code and is not (yet) easily generalizable.
>
> -Brad
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110725/6b9cba40/attachment.htm>