<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <<a href="mailto:mateusz@loskot.net">mateusz@loskot.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 19 May 2018 at 15:00, Elvis Stansvik <<a href="mailto:elvis.stansvik@orexplore.com" target="_blank" rel="noreferrer">elvis.stansvik@orexplore.com</a>> wrote:<br>
> I know this has been asked before, but I've never seen a really<br>
> authoritative answer.<br>
><br>
> Say I have a simple single-library project.<br>
><br>
> The advise I've seen is to not pass SHARED or STATIC to the<br>
> add_library(..), but instead let the user pass<br>
> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared<br>
> or static.<br>
><br>
> That's fine, but leads to packagers having to do ugly things like e.g:<br>
><br>
>     <a href="https://salsa.debian.org/hle/dlib/blob/master/debian/rules" rel="noreferrer noreferrer" target="_blank">https://salsa.debian.org/hle/dlib/blob/master/debian/rules</a><br>
><br>
> That is, do two separate configure/build/install, in order to get both<br>
> a shared and static version.<br>
<br>
IMHO, there is nothing ugly in this approach.<br>
Not every system allows (or recomments) to generate both,<br>
static and shared, from the same object files.<br>
Why not view static vs shared as the similar to 32 vs 64 bit?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Because they are different architectures that in many cases require different compilers and in some cases different host machines to run on. Static vs shared has none of these issues to contend with.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best regards,<br>
-- <br>
Mateusz Loskot, <a href="http://mateusz.loskot.net" rel="noreferrer noreferrer" target="_blank">http://mateusz.loskot.net</a><br>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://cmake.org/mailman/listinfo/cmake" rel="noreferrer noreferrer" target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br>
</blockquote></div></div></div>