[CMake] Problem with design and ADD_SUBDIRECTORY

[Martin Santa Maria]

Thanks to all for your answers. 

The thing is that I don't want to code statically the existence of packages
in the root/CMakeLists.txt but I want that each package register it-self in
some "package container" that the CMakeLists.txt could read. This container
should be seen as a set of lists and variables that contains, for example,
the source files or some flags. I was having problem with ADD_SUBDIRECTORY
because the only way I found to pass the information from package's
CMakeLists.txt files to the root's CMakeLists.txt was using cache variables
but this doesn't work completely because the variables are not reinitialized
on each configure and I had an growing list of things.

I think I will success with PARENT_SCOPE flag and some macros. I tell you
soon. Regards

Martin

> -----Original Message-----
> From: Tyler Roscoe [mailto:tyler at cryptio.net] 
> Sent: Tuesday, July 14, 2009 5:31 PM
> To: Martin Santa María
> Cc: cmake at cmake.org
> Subject: Re: [CMake] Problem with design and ADD_SUBDIRECTORY
>
> On Tue, Jul 14, 2009 at 12:08:43PM -0300, Martin Santa María wrote:
> > root/
> >   CMakeLists.txt   -> generates executable with some package libraries
> >   package1/
> >     CMakeLists.txt -> generates package1.lib
> >   package2/
> >     CMakeLists.txt -> generates package2.lib that depends on package1
library and its header files. so it must include root/package1/
> > 
> > 
> > My problem begins with INCLUDE_DIRECTORIES and LINK_DIRECTORIES. I
> > would like that packages include those directories that are really
> > needed to search for headers and libraries, in the previous example
> > package2 should includes directory package 1 so it could find
> > package1's headers, but package1 shouldn't know about package2. To
>
> Why does it matter if package1 "knows about" package2? What do you mean
> by "know about"?
>
> > archive this, I think I need to use ADD_SUBDIRECTORY so each sub
> > directory has its own includes and libraries directories. The problem
>
> Yes, the root project should probably add_subdirectory() both package
> projects. Is this not how you're doing it now?
>
> > is that the root CMakeLists.txt should known the list of generated
> > libraries and source files so it could make the global executable.  I
> > don't find the way to pass this information from package's
> > CMakeLists.txt to the root CMakeLists.txt.
>
> I'm afraid I still don't understand the problem, or your question.
>
> set() has a PARENT_SCOPE flag that might help you? But I have a feeling
> you're over-thinking this.
>
> tyler
>
> -----Original Message-----
> Message: 2
> Date: Tue, 14 Jul 2009 17:35:26 +0200
> From: Andreas Pakulat <apaku at gmx.de>
> Subject: Re: [CMake] Problem with design and ADD_SUBDIRECTORY
> To: cmake at cmake.org
> Message-ID: <20090714153526.GA8052 at trinity.apaku.dnsalias.org>
> Content-Type: text/plain; charset=iso-8859-1
>
> On 14.07.09 12:08:43, Martin Santa Mar?a wrote:
> > 
> > Hello everyone,
> > 
> > I have a design problem. I have a new project consisting on different
packages. Each package should be built as a library but it could depend on
libraries generated by other packages. Also there is an executable built
from some of these libraries:
> > 
> > root/
> >   CMakeLists.txt   -> generates executable with some package libraries
> >   package1/
> >     CMakeLists.txt -> generates package1.lib
> >   package2/
> >     CMakeLists.txt -> generates package2.lib that depends on package1 
> > library and its header files. so it must include root/package1/
> > 
> > 
> > My problem begins with INCLUDE_DIRECTORIES and LINK_DIRECTORIES. 
>
> Don't use link_directories, instead use target_link_libraries and name the
needed targets in there. So for package2/CMakeLists.txt you'd have:
>
> add_library( package2 SHARED <sources> )
> target_link_libraries(package2 package1)
>
> For include dirs of package2/CMakeLists.txt you can just do:
>
> include_directories( "${CMAKE_SOURCE_DIRECTORY}/package1" )
>
> > archive this, I think I need to use ADD_SUBDIRECTORY so each sub
>
> Right.
>
> > The problem is that the root CMakeLists.txt should known the list of 
> > generated libraries and source files so it could make the global 
> > executable.
>
> Again, you can simply use the target names:
>
> target_link_libraries(rootexec package1 package2 package4 package7)
>
> If the number of libs depends on certain options you can simply build up a
list of actually built targets:
>
> set( LIBS ${package2} )
> if(OPTION_FOO)
>   set( LIBS ${LIBS} package1)
> else(OPTION FOO)
>   set( LIBS ${LIBS} package3)
> endif(OPTION_FOO)
>
> Andreas
>
> ------------------------------
>
> Message: 7
> Date: Tue, 14 Jul 2009 11:21:41 -0400
> From: Michael Jackson <mike.jackson at bluequartz.net>
> Subject: Re: [CMake] Problem with design and ADD_SUBDIRECTORY
> To: Cmake Mailing List <cmake at cmake.org>
> Message-ID: <61E5FC9F-19B1-4CA0-B6EE-4ABD4D15B2D0 at bluequartz.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
>
> In the top level CMakeLists.txt you should be able to do something like:
>
> add_executable(Foo .. )
> target_link_libraries(Foo package1 package2)
>
> and it should just work. CMake will figure out the dependencies.
>
> Also in package2/CMakeLists.txt
>
>   target_link_libraries(package2 package1)
> will work the same way.
>
> As far as the include directories goes there are different ways to  
> solve that issue. One way would be to define some variables in the  
> root level CMakeLists.txt file such as:
>   set(PACKAGE1_SRC_DIR  ${ROOT_SRC_DIR}/package1)
>   set(PACKAGE2_SRC_DIR  ${ROOT_SRC_DIR}/package2)
>
> Each of those variables will be available in all the other sub- 
> directories as cmake variables can be passed down the chain.
>
>   You could also define the variables in each sub-directory and use  
> the "PARENT_SCOPE" argument to the "SET()" command although I am not  
> sure if that would work or not.
>
> HTH
> _________________________________________________________
> Mike Jackson                  mike.jackson at bluequartz.net
> BlueQuartz Software                    www.bluequartz.net
> Principal Software Engineer                  Dayton, Ohio