[CMake] Fwd: Targets organisation of complex project

Mateusz Loskot mateusz at loskot.net
Mon Oct 12 17:26:46 EDT 2009


Hi Chris,

Yes, but no problem at all.

Thank you very much for all the details, they are very helpful.
Your approach looks good for our project, but letting myself to learn
more ideas like the one project.cmake  vs CMakeLists.txt by Pau Garcia.

Mat


Chris Foster wrote:
> [ Ugh, I replied to this as a private message to Mateusz by mistake.
> I'm forwarding it to the list as I hope it may be of general interest. Sorry! ]
> 
> 
> ---------- Forwarded message ----------
> From: Chris Foster <chris42f at gmail.com>
> Date: Mon, Oct 12, 2009 at 9:18 AM
> Subject: Re: [CMake] Targets organisation of complex project
> To: Mateusz Loskot <mateusz at loskot.net>
> 
> 
> Hi Mateusz,
> 
> On Mon, Oct 12, 2009 at 5:41 AM, Mateusz Loskot <mateusz at loskot.net> wrote:
>> The sources are organised in large number of subdirectories and
>> sort of logical sub-libraries, but the binary output of compilation
>> is a single library.
>>
>> Trying to figure out how to organise targets I got an idea to
>> configure these sub-libraries as static library targets
>> (e.g. libgdal_cpl, libgdal_alg, libgdal_gcore, etc.) which
>> eventually link to single shared library (libgdal.so).
> 
> As you've seen, doing this won't work in many cases :-(
> 
> I've grappled with the same problem recently when rewriting the build system
> for the aqsis renderer project.  I certainly don't know what's *best*, but I
> did find a solution which somewhat satisfied me.  Let's suppose we have two
> individual subdirectories, libA and libB, and we want to combine them
> together.
> 
> Here's how I have laid that kind of thing out in aqsis:
> 
> src/
>    CMakeLists.txt
>    libA/
>        project.cmake
>        ... lots of source
>    libB/
>        project.cmake
>        ... lots of source
> 
> The idea is to define a file (arbitrarily named "project.cmake" in my system)
> in the individual library directories which defines variables corresponding to
> the library source.  The main CMakeLists.txt then include()s these files,
> makes a source list from all the individual sources, and uses those in an
> add_library command to create the final library.  I wrote some macros to
> automate the inclusion process a little better so that the project.cmake files
> were a bit like what you'd normally write in a CMakeLists.txt.
> 
> The system has some remaining shortcomings - in particular the project.cmake
> files still look more different from a plain CMakeLists.txt than I'd like -
> but perhaps it can give you some ideas.  You can browse the aqsis source tree
> online at
> 
> http://aqsis.git.sourceforge.net/git/gitweb.cgi?p=aqsis/aqsis;a=tree
> 
> If you're interested, I would suggest you look at the file
> libs/core/CMakeLists.txt and the project.cmake files in the subdirectories of
> libs/core/.  Here's an overview of the relevant directory structure:
> 
> libs/core/
>    CMakeLists.txt
>    api/
>        project.cmake
>    ddmanager/
>        project.cmake
>    geometry/
>        project.cmake
>    raytrace/
>        project.cmake
> 
> To see the macros which are used (in particular, add_subproject and related
> macros), have a look at the file cmake/UtilMacros.cmake
> 
> HTH,
> ~Chris.
> _______________________________________________
> 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
> 


-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org


More information about the CMake mailing list