<div dir="auto"><div>I understand your<br><br><div data-smartmail="gmail_signature">Mateusz Loskot, <a href="mailto:mateusz@loskot.net">mateusz@loskot.net</a><br>(Sent from mobile) </div><br><div class="gmail_quote"><div dir="ltr">On Sat, 19 May 2018, 22:54 Ray Donnelly, <<a href="mailto:mingw.android@gmail.com">mingw.android@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Sat, May 19, 2018, 9:38 PM Mateusz Loskot <<a href="mailto:mateusz@loskot.net" target="_blank" rel="noreferrer">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 22:16, Ray Donnelly <<a href="mailto:mingw.android@gmail.com" rel="noreferrer noreferrer" target="_blank">mingw.android@gmail.com</a>> wrote:<br>
> On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <<a href="mailto:mateusz@loskot.net" rel="noreferrer noreferrer" target="_blank">mateusz@loskot.net</a>> wrote:<br>
>> On 19 May 2018 at 15:00, Elvis Stansvik <<a href="mailto:elvis.stansvik@orexplore.com" rel="noreferrer noreferrer" target="_blank">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 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>
><br>
><br>
> Because they are different architectures that in many cases require<br>
> different compilers and in some cases different host machines to run on.<br>
> Static vs shared has none of these issues to contend with.<br>
<br>
Both, static and shared may use quite different compilation/linking,<br>
that is enough to treat them differently.<br>
Apparently, my point hasn't made it through. Nevermind.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes of course they do but the tooling in and around cmake (including things like pkg-config and libtool) support this already. All I am pushing for is for parity between the main 3 OSes here so that users of cmake do not have to implement ugly hacks purely due to this.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I understand. I just have learned to live with lacking of such parity in CMake.</div><div dir="auto">Look, CMake does not event abstract such a basic thing as filesystem case-sensitivity, for example</div><div dir="auto"><div dir="auto"><br></div><div dir="auto">find_package(protobuf)</div><div dir="auto">vs</div><div dir="auto">find_package(Protobuf)</div><div dir="auto"><br></div><div dir="auto">The former won't work on OS witch case-sensitive filesystem.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Best regards, </div><div dir="auto">Mateusz Loskot </div></div><div dir="auto"><br></div><div dir="auto"><br></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">
</blockquote></div></div></div>