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