[CMake] faking convenience libraries

Brandon J. Van Every bvanevery at gmail.com
Tue Jan 23 23:46:34 EST 2007


Bill Hoffman wrote:
> Brandon J. Van Every wrote:
>>
>> For clarity, let's say I make 2 static libraries:
>> - pcre_static_pic, for use with our shared libchicken et al
>> - pcre_static_nopic, for use with our libchicken-static et al
>>
>> The latter case runs into the "static library as part of a static 
>> library" problem.  

Er, I'd better sanity check.  Is there a corresponding "static library 
as part of a dynamic library" problem?  Or can "ar" handle that just 
fine?  I just wrote new versions of our CMakeLists.txt's, thinking I 
could eliminate the duplicate builds at least for the dynamic case.  I 
hope I wasn't wasting my time.


>> If CMake can indeed handle the chaining of static libraries,
>>
> CMake does not directly support this.   However, you can put a full 
> path to a .o file as a source for a library and cmake will do the 
> right thing for with it.  The catch is I have never done this, and it 
> will be difficult to figure out the paths to the .o files, 

Is there a "safe" way to find the paths, that doesn't rely on magical 
CMake internals?  If there is no safe way, is there a way that minimizes 
the risk of CMake internals changing?

I see problems with any approaches based on FIND_PATH.  Even if I use it 
from a CMake script, so that I can search for .obj files after they've 
already been built, I think the path needs to be specified at 
configuration time.  That means I need to predict the path, not detect it.

I could write a custom C compilation rule, but that seems to defeat the 
purpose of using CMake.  It will make passing definitions and other 
flags a real chore.


Cheers,
Brandon Van Every



More information about the CMake mailing list