[CMake] Handling library dependencies and minimizing duplicated include_directories

Mon Mar 22 20:47:15 EDT 2010

So... no easy answer for this? The only reason I bring this up is that 
I've looked at the cmake version of boost, and it requires a library of 
several cmake files full of macros and functions that help get their 
project organization to work with cmake. I've had to resort to the same 
kind of thing. ADD_LIBRARY just didn't cut it. I like that cmake allows me 
to get to the functionality I want, but it seems that it becomes a 
scripting language at that point, and cmake is certainly not a scripting 
language. Boost for example has numerous helper functions or macros for 
using named arguments with macros and functions. (They are all very 
cleaver and I totally use them in my project.) Another example is that my 
project has functions and macros for adding the dependencies between 
libraries, dependencies like include directories, link directories, and 
link libraries. Is there something on the horizon for CMake to address 
these issues? Or have they been addressed, but I've missed them?

On a side note, I see questions for this kind of thing all the time on 
this mailing list. I never see a very good answer. Perhaps a wiki page or 
a blog could be made covering project organization. It could perhaps cut 
down on repeat questions.

-------------------------------------------------------------
Aaron Wright

From:
Aaron_Wright at selinc.com
To:
Michael Jackson <mike.jackson at bluequartz.net>
Cc:
cmake at cmake.org
Date:
03/22/2010 07:47 AM
Subject:
Re: [CMake] Handling library dependencies and minimizing duplicated 
include_directories
Sent by:
cmake-bounces at cmake.org

You mean in the case of a master CMakelists.txt file I assume? That does 
work, and I like that functionality. The same kind of thing works for 
Visual Studio solutions as well. I just don't think this fits the usual 
paradigm of building my developers and I are used to. 

For example, if they want to work on a library, they would instinctively 
go to that library and make a build folder and run CMake. They would not 
think to go to the top of the directory tree, create a build folder in a 
location they never make folders or files or do any work, and then 
progress down the build folder's directory path to the library they want 
to build. Which is in a completely different location than the source 
files of the library, which they'll soon be modifying. 

This would all work though, so it is a valid solution. 

-------------------------------------------------------------
Aaron Wright 

From: 
Michael Jackson <mike.jackson at bluequartz.net> 
To: 
Aaron_Wright at selinc.com 
Cc: 
cmake at cmake.org 
Date: 
03/22/2010 07:32 AM 
Subject: 
Re: [CMake] Handling library dependencies and minimizing duplicated 
include_directories

If you are using any of the "Makefile" generators, you can simply 
drill down into the folder of the library you want to build and issue 
the "make" command. The library, and anything that it depends on will 
be built (or rebuilt) accordingly.
___________________________________________________________
Mike Jackson                      www.bluequartz.net

On Mar 22, 2010, at 9:52 AM, Aaron_Wright at selinc.com wrote:

> I've always been a little confused by FIND_PACKAGE and those "*- 
> config.cmake" files. So much so that I didn't use them in my build 
> system at all. The main question I have is that I have several 
> developers and numerous little and big libraries. Because the whole 
> project is so big it would be prohibitive for them all to work from 
> a master CMakeLists.txt file at the top. I want each developer to be 
> able to go the folder of the library they want to work on today and 
> start building there. I want all the libraries that library depends 
> on to be built or rebuilt if anything has changed in addition to 
> building the current library.
>
> I've been unable to find a simple solution to this problem using 
> CMake, which makes me wonder if what I'm doing is off the wall, but 
> it sounds so normal to me. I see these "*-config.cmake" files but it 
> seems they are generated from a CMakelist.txt file, which wouldn't 
> make any sense, because I'm not going to have a developer go to each 
> dependant library and build it seperately so that the "*- 
> config.cmake" can be generated so that he can have those variables 
> back in the library he really wants to build.
>
> What am I missing?
>
> -------------------------------------------------------------
> Aaron Wright
>
>
>
> From:
> Daniel Lidström <daniel.lidstrom at sbg.se>
> To:
> Cc:
> <cmake at cmake.org>
> Date:
> 03/20/2010 01:25 PM
> Subject:
> Re: [CMake] Handling library dependencies and minimizing 
> duplicated        include_directories
> Sent by:
> cmake-bounces at cmake.org
>
>
>
>
> > If the projects UMC3D, GFL etc can be used independently, but
> > are all "under your control", then you shouldn't write
> > FindUMC3D.cmake, FindGFL.cmake etc files, but create
> > UMC3D-config.cmake, GFL-config.cmake etc files instead. Read
> > the documentation of the FIND_PACKAGE command, especially the
> > paragraphs about the "config mode". You'll also find many
> > discussions on this in the archives of this list.
>
> Thanks a lot for your help Mike!
>
> Regards,
>
> Daniel Lidström
> Stockholm, Sweden
> _______________________________________________
> 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
>
> _______________________________________________
> 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

_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100322/9bf7f884/attachment-0001.htm>