[CMake] Handling library dependencies and minimizing duplicated include_directories

J Decker d3ck0r at gmail.com
Mon Mar 22 21:06:48 EDT 2010


On Mon, Mar 22, 2010 at 7:46 AM, <Aaron_Wright at selinc.com> wrote:

> 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.
>
>
Ya, I'm about to face this too... I've previously setup Makefiles to be able
to build at any sub part of the tree so you can just work there.. otherwise
I end up having to maintain several consoles, one in the output, one in the
source, and one in the specific part of the tree built by cmake, else having
to remake the whole thing over and over which is taking up to minutes.

I also notice that building with cmake triggers excecutions of make much
more than my previous Make only solution did... so it's kidna slow even in
building a single source library, and a 2 second build for 100 tiny
libraries adds a LOT of time.  I Would think that cmake would be able to
generate a master makefile that contained all rules and targets, and
basically invoke the make once instead of once per file or library to
buildl.

Maybe CMake 4.0 will do this :)  But that's just a dream.

I've also started running cmake from entirely outside the source tree, which
adds the benefit that I can mass compare source trees which are not
corrupted by additional build products.



> -------------------------------------------------------------
> Aaron Wright
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100322/6711210d/attachment.htm>


More information about the CMake mailing list