[CMake] ProjectConfig.cmake files with both dynamic and static libraries?

[Ben Morgan]

Hi Michael,

On Thu, May 5, 2011 at 10:48 PM, Michael Hertling <mhertling at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110509/d6113b1d/attachment-0001.htm>