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.
If, on the other hand, I have to produce the *.o files,
You can put .o files into the list of sources for a cmake target. I
suppose you could get something that would only build the stuff twice,
once for shared and once for static. And use target_depends to make
sure things are built in the right order...
then I'll go ahead and do that. Just making sure I 100% understand your
answer.
Cheers,
Brandon Van Every
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
