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
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
