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

2018-05-19 Thread Ray Donnelly
On Sat, May 19, 2018 at 11:55 PM, Elvis Stansvik wrote: > 2018-05-19 21:49 GMT+02:00 Mateusz Loskot : >> On 19 May 2018 at 15:00, Elvis Stansvik 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.

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

2018-05-19 Thread Elvis Stansvik
2018-05-19 21:49 GMT+02:00 Mateusz Loskot : > On 19 May 2018 at 15:00, Elvis Stansvik 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 t

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

2018-05-19 Thread 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, mate...@loskot.net (Sent from mobile) On Sun, 20 May 2018, 00:03 Mateusz Loskot, wrote: > I understand your > > Mateusz Losk

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

2018-05-19 Thread Mateusz Loskot
I understand your Mateusz Loskot, mate...@loskot.net (Sent from mobile) On Sat, 19 May 2018, 22:54 Ray Donnelly, wrote: > On Sat, May 19, 2018, 9:38 PM Mateusz Loskot wrote: > >> On 19 May 2018 at 22:16, Ray Donnelly wrote: >> > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot >> wrote: >> >> On

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

2018-05-19 Thread Ray Donnelly
On Sat, May 19, 2018, 9:38 PM Mateusz Loskot wrote: > On 19 May 2018 at 22:16, Ray Donnelly wrote: > > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot wrote: > >> On 19 May 2018 at 15:00, Elvis Stansvik > wrote: > >> > I know this has been asked before, but I've never seen a really > >> > authori

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

2018-05-19 Thread Mateusz Loskot
On 19 May 2018 at 22:16, Ray Donnelly wrote: > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot wrote: >> On 19 May 2018 at 15:00, Elvis Stansvik wrote: >> > I know this has been asked before, but I've never seen a really >> > authoritative answer. >> > >> > Say I have a simple single-library projec

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

2018-05-19 Thread Ray Donnelly
It most definitely is not. I work on a cross platform software distro that includes many hundreds on libraries. There are 3 competing standards (4 if you include mingw-w64): lib prefix: ugly when the lib is already prefixed with lib. -static.lib suffix. .dll.lib vs .lib. The point is cmake has de

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

2018-05-19 Thread Ray Donnelly
On Sat, May 19, 2018, 8:50 PM Mateusz Loskot wrote: > On 19 May 2018 at 15:00, Elvis Stansvik > 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 SHA

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

2018-05-19 Thread Mateusz Loskot
On 19 May 2018 at 15:00, Elvis Stansvik 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

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

2018-05-19 Thread Shoaib Meenai
The convention in MSVC-land seems to be to prefix (as well as suffix) static libraries with lib. E.g. the static CRT is libcmt.lib, the static VC runtime support library is libvcruntime.lib (whereas the import library for the dynamic equivalent is vcruntime.lib), and so on. It isn't necessarily

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

2018-05-19 Thread Jacob Barrett
The Apache Geode Native [1] project needs to build both the shared, for releasing, and the static, unit testing and embedding in mix-mode .NET assembly. We tackled this by creating an INTERFACE library [2] that contains the common elements of both shared and static then having SHARED [3] and STATIC

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

2018-05-19 Thread Elvis Stansvik
2018-05-19 15:09 GMT+02:00 Ray Donnelly : > And the situation is *far* worse on Windows where the extension for a dll > import library is the same as for a static library because cmake refuses to > try to move the needle on this awful 'defacto' decision with respect to msvc > when it is exactly the

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

2018-05-19 Thread Ray Donnelly
And the situation is *far* worse on Windows where the extension for a dll import library is the same as for a static library because cmake refuses to try to move the needle on this awful 'defacto' decision with respect to msvc when it is exactly the sort of thing cmake should strive to take the lea

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

2018-05-19 Thread Elvis Stansvik
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 eith