On Mon, Oct 12, 2009 at 6:41 AM, Chris Foster <chris...@gmail.com> wrote: > On Mon, Oct 12, 2009 at 12:57 PM, Pau Garcia i Quiles > <pgqui...@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) _______________________________________________ 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