[CMake] faking convenience libraries

Bill Hoffman bill.hoffman at kitware.com
Tue Jan 23 08:59:16 EST 2007


Brandon J. Van Every wrote:
> Bill Hoffman wrote:
>> Brandon J. Van Every wrote:
>>> Bill Hoffman wrote:
>>>
>>> There are no other differences in the PCRE library.  It is straight 
>>> C code, not Chicken output, so it doesn't need any of Chicken's 
>>> usual flags.  It is a properly independent sub-library.  We just 
>>> don't want to have people doing -lchicken -lpcre, we want the PCRE 
>>> library embedded in -lchicken.
>> So, in a perfect world, (where everyone uses CMake :-)  ) this would 
>> not be a problem.  Because cmake will automatically chain the 
>> dependent libraries.  The user only has to specifiy -lchicken and 
>> cmake will add the -lpcre.   
>
> 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.  You're saying CMake handles this?  I thought on 
> some platforms, the underlying "ar" tool can't handle this.  The CMake 
> archives also seemed to indicate this, although I didn't look closely 
> at the posting date of the archives.  If CMake can indeed handle the 
> chaining of static libraries, I would prefer to do that.  It's cleaner 
> / easier to specify in the build, especially if other people aren't 
> CMake experts.
>
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, and make sure they 
are built before they are used in the archive.  It may or may not be 
possible to do what you want, and I am sure it will be ugly....

-Bill



More information about the CMake mailing list