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

[Elvis Stansvik]

2018-05-20 4:19 GMT+02:00 Ray Donnelly <mingw.android at gmail.com>:
> On Sat, May 19, 2018 at 11:55 PM, Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
>> 2018-05-19 21:49 GMT+02:00 Mateusz Loskot <mateusz at loskot.net>:
>>> 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.
>>
>> Alright. Yes I'm probably personally leaning towards just using the
>> recommended way, with a single add_library(..) and demand
>> reconfigure/rebuild/reinstall to get both variants. I was mostly
>> curious if you CMake pros on this list had some neat solution I hadn't
>> seen before.
>>
>> Note that I wasn't necessarily suggesting building shared + static
>> from the same set of object files (which is indeed not recommended,
>> e.g. think of -fPIC),
>
> Static libraries should be compiled with -fPIC on all systems that
> support -fPIC. The reason for this is that you should not make
> assumptions about the final target of the static library. There is no
> reason it should be excluded from being linked into a shared library
> or a ASLR capable executable. On Anaconda Distribution, everything is
> compiled with -fPIC on Linux for this reason, and on macOS, -fPIC is
> the only option and Windows has always been PIC or at least for as
> long as I can remember.

Alright, this was some good bit of info, since I had mostly seen "PIC
unnecessarily hurts performance for static libs" kind of advice out
there.

Thinking about it, in my case, even if PIC did hurt performance a bit,
I don't think it's much enough that I should care, for my use case at
least.

So, with that in mind, is anyone doing this:

- Build an object library (with POSITION_INDEPENDENT_CODE)
- Build a static library from the object library
- Build a shared library from the object library

? Any downsides/gotchas with this approach?

The upsides I see are:

1. Sources are compiled once, and the result linked twice.
2. No need for a variable to hold the list of sources.

Time savings of 1 may be negligible though, if linking is the lion
share of the time (my project is tiny though, so I'm not concerned
about build time savings).

Elvis

>
> but just looking for best practices when having
>> CMake do the build of both libraries as part of the same build.
>>
>> Elvis
>>
>>> Why not view static vs shared as the similar to 32 vs 64 bit?
>>>
>>> Best regards,
>>> --
>>> Mateusz Loskot, http://mateusz.loskot.net
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://cmake.org/mailman/listinfo/cmake
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake