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

[Ray Donnelly]

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.

>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180519/6f054af0/attachment.html>