[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