Hi Michael, On Thu, May 5, 2011 at 10:48 PM, Michael Hertling <mhertl...@online.de>wrote:
> > IMO, your approach looks quite reasonable; however, I'm not completely > happy with it... ;) Please note that the following remarks are just my > personal point of view, and of course, one can have different notions. > > The information if there is a static library is already available at > mlvl's configuration time, so there's no actual need for the config > file to make a dynamic decision, i.e. "if(TARGET mlvl-static)" and > "if(mlvl_LIBRARY_STATIC)"; this is typically done by find modules. > Instead, one might consider to hard-code the affected passages, > e.g. as an additional include file next to the export file: > Thanks for the suggestions - they look really useful (and an improvement over my current setup)! I used the odd mlvl_LIBRARY_STATIC variable to try and allow for cases where a project might need the static library for one target but the shared library for another. The only case I can think of for this is if I build another library 'foo' which can be built static and shared, and which links to mlvl. I might then want to target_link_libraries foo-static to mlvl-static, and foo to mlvl so that clients of foo can get pure static or dynamic builds. I don't know if that'll be needed, or if it's even a good idea. Besides, an approach like the above-noted would make it much easier for > the user to explicitly prefer a static library to a shared one without > messing around with CMAKE_FIND_LIBRARY_SUFFIXES or setting XYZ_LIBRARY > explicitly, an issue which comes up on the ML every now and then. In > addition, if you drop the mutual exclusion, you gain the possibility > to link against the shared and the static library at the same time in > case they differ in some regard. That's hardly possibly with the usual > single-component approach although I don't have an example at hand ATM. > > However, when thinking about multi-component packages, be aware of some > issues that do not matter for single-component packages, refer to [1,2] > for discussions of this topic. Furthermore, note that an export file as > mlvlLibraryDepends.cmake needs to be protected from being included more > than once in the current scope, see [3]. > > Regards, > > Michael > > [1] http://www.mail-archive.com/cmake@cmake.org/msg28431.html > [2] http://www.mail-archive.com/cmake@cmake.org/msg32836.html > [3] http://www.mail-archive.com/cmake@cmake.org/msg35873.html Yes, the basic idea was to provide the option for static or dynamic linking in an easy way. The ProjectConfig.cmake approach is very nice for handling this, with the caveats you mention above. Many thanks for the example code for components and the links - they're going to be really helpful. Cheers, Ben.
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
