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

[Mateusz Loskot]

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/cda0b164/attachment.html>