[CMake] automagically generated header hell

Mike Talbot mtalbot at abingdon.oilfield.slb.com
Fri Jun 30 10:27:11 EDT 2006


I have a similar problem, except that using ADD_DEPENDENCIES to make the 
library with generated files a dependency of the targets that use it, 
causes the target libraries to include a copy of the dependent library 
when built as static libraries with VC71 (this is a long standing 
(mis)feature of visual studio).  Since my generated library is large, 
the resulting build ends up being huge.

Anyway, strictly speaking the (non-generated) targets only depend on the 
generated header files to compile.  (For linking it will be handled 
correctly anyway via TARGET_LINK_LIBRARIES.)  Looking at a make-based 
build it seems that if the generated header files exist, they are 
included in the dependencies of the source files using them, however in 
a clean build they don't exist yet, so aren't listed as dependencies.  
Since the generated header files have the GENERATED property set to true 
would it be possible for the dependency scan to include these files as 
dependencies even though they don't yet exist?  It would then correctly 
go an generate the header files before compiling files that include them.

Mike

David Somers wrote:
> In a project I'm workking on I use makeheaders 
> (http://www.cvstrac.org/cvstrac/dir?d=cvstrac) to automagically generate the 
> h files for my c files.
>
> I'm using ADD_CUSTOM_TARGET to generate the headers, and some ADD_DEPENDENCIES 
> magic to ensure they're generated before the code is compiled.
>
> All works quite well.
>
> However, as the cmake wiki says "Note that generated headers can often cause 
> unnecessary rebuilds and should be avoided if possible." And I've run into 
> this problem :-(
>
> I have a library that depends on an application being done first (so that the 
> library can pull in some of the headers that are generated when the app is 
> made). Using ADD_DEPENDENCIES this is working automagically, but the problem 
> I've hit is that the library has rebuild problems (i.e. it make will rebuilt 
> it even when everything in it is up-to-date).
>
> Is there some way to 'persuade' cmake that in my library when foo.c does 
> #include <bar.h> that it shouldn't add <bar.h> into the dependencies (because 
> I've manually taken care of that elsewhere)?
>
>   



More information about the CMake mailing list