I hope clarifies the core problem I rambled on about in my last message. Suppose I am building project Foo which depends on libA which has an optional dependency on libB. It looks like everyone just does
find_library (A_LIBRARY A) and calls it good. If libA is a shared library, the linker can track down the recursive dependencies so everything will just work, but if libA is static, then libB must be passed to the linker *if* libA was built with libB. How should one handle this logic? What I've been doing is parsing the link line provided by libA's build system and adding all the libraries to A_LIBRARIES. For shared libs, it really is better to only pass libA to the linker. Since Foo will never call into libB directly, I could upgrade libA to link against libB2 (or reconfigure libA to not link against libB, then uninstall libB) and as long as libA maintains a stable ABI (doesn't bump soname), Foo would not need to be relinked. But I have to support systems which only have static libs so I can't rely on the linker to track down the recursive dependencies. Here is an extremely simple test case that is broken on every platform where libtiff is a static library. http://59a2.org/files/cmake-tiff.tar.gz CMake configures successfully, but the build fails with lots of unresolved symbols. The user needs to manually add the dependency graph of libtiff (libjpeg, libz, libm) to an advanced variable to link properly. Do others not consider this to be broken behavior? What if the dependency graph is dynamic (depends on configuration) and may consist of 40 libraries scattered throughout the filesystem, but there is an algorithmic way to find them (by parsing a link line provided by the libA build system)? It seems to me that all modules should be providing this dependency graph when they are finding static libraries, otherwise the user is left with a nightmare of manually tracking it down. Are there no CMake developers on systems without shared libs? Jed
pgpCwsUNNfs03.pgp
Description: PGP signature
_______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
