[CMake] faking convenience libraries

[Bill Hoffman]

Brandon J. Van Every wrote:
> 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.
>
I would try it first....   If you link a static library to a shared one 
it should work, as long as the static has -pic.   It should work on 
windows as well, as long as you do not want to export symbols from the 
static library.
>
>>> 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.
>
>
I did say it was difficult.... :-)

You can not use FIND_* stuff because the files will not be there.   
There is a risk that cmake could change where the .o files are put.  To 
mitigate that risk, I would recommend setting up everything with 
variables.   You already have these 
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}.  That will give you the 
CMakeFiles directory, then each library is in LibName.dir and the obj 
files should be in there.   It would be safest to write a macro that 
converts a source name into a .o name, that way if cmake changes, you 
can just change the macro.

-Bill