[CMake] Fwd: Targets organisation of complex project

[Pau Garcia i Quiles]

On Mon, Oct 12, 2009 at 6:41 AM, Chris Foster <chris42f at gmail.com> wrote:
> On Mon, Oct 12, 2009 at 12:57 PM, Pau Garcia i Quiles
> <pgquiles at elpauer.org> wrote:
> [...]
>> What are the advantages of this? Why don't you rename you
>> "project.cmake" files to "CMakeLists.txt" and use add_subdirectory on
>> those directories? I see no difference :-?
>
> The difference is becase custom code generation rules seem to be local to
> subdirectories.  I've made up an example (attached as a tgz file) to
> demonstrate what I mean.  The directory layout is:
>
> CMakeLists.txt
> libA/
>     CMakeLists.txt
>     hello2.in.cpp
>     hello.cpp
> libB/
>     CMakeLists.txt
>     goodbye.cpp
>
>
> And inside CMakeLists.txt, I want to build a shared library "libgreeting" which
> consolidates all the sources together, that is, all of
>
>  hello.cpp
>  hello2.cpp (generated from libA/hello2.in.cpp)
>  goodbye.cpp
>
>
> The problem is that when hello2.cpp is generated, I would like to specify the
> generation rules (with add_custom_command) inside libA/CMakeLists.txt to have
> everything for libA nicely encapsulated in one place.  However, the build rules
> created by add_custom_command seem to be local to the libA subdirectory, and I
> don't know how to get the base CMakeLists.txt to see them when using
> add_subdirectory().  With include() this problem goes away because the build
> rules are actually included into the current file.
>
> Try to run the simple example I'm attaching and you'll see that cmake complains
> about not knowing how to build hello2.cpp.  Setting the GENERATED property
> in the base CMakeLists.txt doesn't help because although it allows cmake to
> generate the build system, the make stage then fails.
>
>
> Mateusz: You may find the example layout I've attached useful if you're not
> needing to do code generation (just delete all the stuff to do with
> hello2.cpp).  You might also consider pulling definitions from the
> subdirectories into the base CMakeLists.txt using something like
>
>  get_directory_property(libA_srcs DIRECTORY libA DEFINITION srcs)
>
> rather than pushing them from the subdirectories into the base scope with
> set(... PARENT_SCOPE)

You are right. IMHO this is a bug in CMake. If you do the
SET_SOURCE_FILES_PROPERTIES in libA/CMakeLists.txt, it should work.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)