[CMake] Approach to both shared and static lib (again, sorry)

[Mateusz Loskot]

Sorry for garbage in previous response.

I top posted partial response and bottom-posted more completed one.

Not easy to edit longish emails on mobile :)

Mateusz Loskot, mateusz at loskot.net
(Sent from mobile)

On Sun, 20 May 2018, 00:03 Mateusz Loskot, <mateusz at loskot.net> wrote:

> I understand your
>
> Mateusz Loskot, mateusz at loskot.net
> (Sent from mobile)
>
> On Sat, 19 May 2018, 22:54 Ray Donnelly, <mingw.android at gmail.com> wrote:
>
>> On Sat, May 19, 2018, 9:38 PM Mateusz Loskot <mateusz at loskot.net> wrote:
>>
>>> On 19 May 2018 at 22:16, Ray Donnelly <mingw.android at gmail.com> wrote:
>>> > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <mateusz at loskot.net>
>>> wrote:
>>> >> On 19 May 2018 at 15:00, Elvis Stansvik <elvis.stansvik at orexplore.com>
>>> wrote:
>>> >> > I know this has been asked before, but I've never seen a really
>>> >> > authoritative answer.
>>> >> >
>>> >> > Say I have a simple single-library project.
>>> >> >
>>> >> > The advise I've seen is to not pass SHARED or STATIC to the
>>> >> > add_library(..), but instead let the user pass
>>> >> > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either
>>> shared
>>> >> > or static.
>>> >> >
>>> >> > That's fine, but leads to packagers having to do ugly things like
>>> e.g:
>>> >> >
>>> >> >     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>>> >> >
>>> >> > That is, do two separate configure/build/install, in order to get
>>> both
>>> >> > a shared and static version.
>>> >>
>>> >> IMHO, there is nothing ugly in this approach.
>>> >> Not every system allows (or recomments) to generate both,
>>> >> static and shared, from the same object files.
>>> >> Why not view static vs shared as the similar to 32 vs 64 bit?
>>> >
>>> >
>>> > 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.
>>>
>>> Both, static and shared may use quite different compilation/linking,
>>> that is enough to treat them differently.
>>> Apparently, my point hasn't made it through. Nevermind.
>>>
>>
>> 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.
>>
>
>
> I understand. I just have learned to live with lacking of such parity in
> CMake.
> Look, CMake does not event abstract such a basic thing as filesystem
> case-sensitivity, for example
>
> find_package(protobuf)
> vs
> find_package(Protobuf)
>
> The former won't work on OS witch case-sensitive filesystem.
>
>
>
> Best regards,
> Mateusz Loskot
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180520/0f3a0fdf/attachment-0001.html>