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

2018-05-20 4:19 GMT+02:00 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

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

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

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

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

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

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

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

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

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

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

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

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 >>

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

vide some distinction, at least. > > > > *From: *CMake <cmake-boun...@cmake.org> on behalf of Ray Donnelly < > mingw.andr...@gmail.com> > *Date: *Saturday, May 19, 2018 at 6:10 AM > *To: *Elvis Stansvik <elvis.stans...@orexplore.com> > *Cc: *CMake MailingList <

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

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

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

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(..),

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

ke@cmake.org> Subject: Re: [CMake] Approach to both shared and static lib (again, sorry) 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' decis

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

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

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

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

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

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

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

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