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