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

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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 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. Note that the above was just an example.
But many packagers do it like this.

How can I make life easier for the packager?

I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
add_library(...), one with SHARED and one with STATIC, but the same
input source files. I could give the two libraries different output
filenames, as to not conflict on e.g. Windows (where I think the .lib
import library containing symbols for the .dll would otherwise
conflict with the static library .lib, or..?).

To not have to repeat the list of sources, I could keep them in a
variable. But that's not recommended in modern CMake AFAIK.

I've also seen people add an object library, and then build the shared
+ static lib from that.

What are your thoughts on all this? How do you go about it? Do you use
the recommended way, with a single add_library(..) and just let
packagers put up with having to do two builds?

Thanks in advance!
Elvis
--

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
Reply | Threaded
Open this post in threaded view
|

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

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 lead on creating this new standard here, in cooperation and discussion with Microsoft (though for pure cmake based things it can be done without that). .dll.lib vs .lib being the obvious extensions here.

FWIW mingw-w64 fixed this, and it was far from difficult. Here we use .dll.a and .a.

I appeal to the CMake moderators to consider the damage this situation causes to the genericness and hygiene of CMakeList.txt files.

On Sat, May 19, 2018, 2:00 PM Elvis Stansvik <[hidden email]> 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. Note that the above was just an example.
But many packagers do it like this.

How can I make life easier for the packager?

I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
add_library(...), one with SHARED and one with STATIC, but the same
input source files. I could give the two libraries different output
filenames, as to not conflict on e.g. Windows (where I think the .lib
import library containing symbols for the .dll would otherwise
conflict with the static library .lib, or..?).

To not have to repeat the list of sources, I could keep them in a
variable. But that's not recommended in modern CMake AFAIK.

I've also seen people add an object library, and then build the shared
+ static lib from that.

What are your thoughts on all this? How do you go about it? Do you use
the recommended way, with a single add_library(..) and just let
packagers put up with having to do two builds?

Thanks in advance!
Elvis
--

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
Reply | Threaded
Open this post in threaded view
|

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

Elvis Stansvik
2018-05-19 15:09 GMT+02:00 Ray Donnelly <[hidden email]>:

> 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 lead on
> creating this new standard here, in cooperation and discussion with
> Microsoft (though for pure cmake based things it can be done without that).
> .dll.lib vs .lib being the obvious extensions here.
>
> FWIW mingw-w64 fixed this, and it was far from difficult. Here we use .dll.a
> and .a.
>
> I appeal to the CMake moderators to consider the damage this situation
> causes to the genericness and hygiene of CMakeList.txt files.

Right, that was the issue I alluded to when I said "I could give the
two libraries different output
filenames, as to not conflict on e.g. Windows (where I think the .lib
import library containing symbols for the .dll would otherwise
conflict with the static library .lib, or..?)".

But I was mostly curious what people are doing when they wish to build
both static and shared, given what the situation is right now (or if
they simply refrain from doing that).

Elvis

>
> On Sat, May 19, 2018, 2:00 PM Elvis Stansvik <[hidden email]>
> 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. Note that the above was just an example.
>> But many packagers do it like this.
>>
>> How can I make life easier for the packager?
>>
>> I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
>> add_library(...), one with SHARED and one with STATIC, but the same
>> input source files. I could give the two libraries different output
>> filenames, as to not conflict on e.g. Windows (where I think the .lib
>> import library containing symbols for the .dll would otherwise
>> conflict with the static library .lib, or..?).
>>
>> To not have to repeat the list of sources, I could keep them in a
>> variable. But that's not recommended in modern CMake AFAIK.
>>
>> I've also seen people add an object library, and then build the shared
>> + static lib from that.
>>
>> What are your thoughts on all this? How do you go about it? Do you use
>> the recommended way, with a single add_library(..) and just let
>> packagers put up with having to do two builds?
>>
>> Thanks in advance!
>> Elvis
>> --
>>
>> 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
Reply | Threaded
Open this post in threaded view
|

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

Jacob Barrett
In reply to this post by Elvis Stansvik
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 [4] libraries include the INTERFACE as a dependency. We also put the static and shared library CMake files in separate directories so that Cotire [5] would work. 

 It isn't perfect but it works pretty good. The biggest downside is that the INTERFACE target can't contain the sources. So at the parent CMake file we jam all the sources in a variable for the children libraries to consume. Something like this, details in the links below.

mylib/CMakeLists.txt:
add_library(INTERFACE _mylib)
target_link_libraries(_mylib INTERFACE Boost::Boost ...)
target_...(_mylib INTERFACE ...)
set(MYLIB_SOURCES mylib.hpp mylib.cpp ...)

mylib/shared/CMakeLists.txt:
add_library(mylib SHARED ${MYLIB_SOURCES})
target_link_libraries(mylib PRIVATE _mylib)

mylib/static/CMakeLists.txt:
add_library(mylib-static STATIC ${MYLIB_SOURCES})
target_link_libraries(mylib-static PUBLIC _mylib)
target_compile_definitions(mylib-static PUBLIC MYLIB_STATIC_DEFINE)

If you check out the links below for details please provide some feedback on improvements we can make. There is lots of stuff going on in these files to support Cotire and some platform differences we couldn't find a better place to deal with. There is also some funkiness with include directories that I haven't investigated fully. 

Would love to hear that there is a better or modern way to attack this problem.

[1] https://github.com/apache/geode-native

-Jake

On Sat, May 19, 2018 at 6:00 AM Elvis Stansvik <[hidden email]> 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. Note that the above was just an example.
But many packagers do it like this.

How can I make life easier for the packager?

I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
add_library(...), one with SHARED and one with STATIC, but the same
input source files. I could give the two libraries different output
filenames, as to not conflict on e.g. Windows (where I think the .lib
import library containing symbols for the .dll would otherwise
conflict with the static library .lib, or..?).

To not have to repeat the list of sources, I could keep them in a
variable. But that's not recommended in modern CMake AFAIK.

I've also seen people add an object library, and then build the shared
+ static lib from that.

What are your thoughts on all this? How do you go about it? Do you use
the recommended way, with a single add_library(..) and just let
packagers put up with having to do two builds?

Thanks in advance!
Elvis
--

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
Reply | Threaded
Open this post in threaded view
|

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

Shoaib Meenai
In reply to this post by Ray Donnelly

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 the greatest scheme, but it does provide some distinction, at least.

 

From: CMake <[hidden email]> on behalf of Ray Donnelly <[hidden email]>
Date: Saturday, May 19, 2018 at 6:10 AM
To: Elvis Stansvik <[hidden email]>
Cc: CMake MailingList <[hidden email]>
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' decision with respect to msvc when it is exactly the sort of thing cmake should strive to take the lead on creating this new standard here, in cooperation and discussion with Microsoft (though for pure cmake based things it can be done without that). .dll.lib vs .lib being the obvious extensions here.

 

FWIW mingw-w64 fixed this, and it was far from difficult. Here we use .dll.a and .a.

 

I appeal to the CMake moderators to consider the damage this situation causes to the genericness and hygiene of CMakeList.txt files.

 

On Sat, May 19, 2018, 2:00 PM Elvis Stansvik <[hidden email]> 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. Note that the above was just an example.
But many packagers do it like this.

How can I make life easier for the packager?

I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
add_library(...), one with SHARED and one with STATIC, but the same
input source files. I could give the two libraries different output
filenames, as to not conflict on e.g. Windows (where I think the .lib
import library containing symbols for the .dll would otherwise
conflict with the static library .lib, or..?).

To not have to repeat the list of sources, I could keep them in a
variable. But that's not recommended in modern CMake AFAIK.

I've also seen people add an object library, and then build the shared
+ static lib from that.

What are your thoughts on all this? How do you go about it? Do you use
the recommended way, with a single add_library(..) and just let
packagers put up with having to do two builds?

Thanks in advance!
Elvis
--

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
Reply | Threaded
Open this post in threaded view
|

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

Mateusz Loskot
In reply to this post by Elvis Stansvik
On 19 May 2018 at 15:00, Elvis Stansvik <[hidden email]> 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?

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
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

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

Ray Donnelly


On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <[hidden email]> wrote:
On 19 May 2018 at 15:00, Elvis Stansvik <[hidden email]> 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.

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
Reply | Threaded
Open this post in threaded view
|

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

Ray Donnelly
In reply to this post by Shoaib Meenai
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 defaults for this and they work on other platforms, instead on Windows it ignores this and leaves the entire software development would to deal with it instead.


On Sat, May 19, 2018, 8:43 PM Shoaib Meenai <[hidden email]> wrote:

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 the greatest scheme, but it does provide some distinction, at least.

 

From: CMake <[hidden email]> on behalf of Ray Donnelly <[hidden email]>
Date: Saturday, May 19, 2018 at 6:10 AM
To: Elvis Stansvik <[hidden email]>
Cc: CMake MailingList <[hidden email]>
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' decision with respect to msvc when it is exactly the sort of thing cmake should strive to take the lead on creating this new standard here, in cooperation and discussion with Microsoft (though for pure cmake based things it can be done without that). .dll.lib vs .lib being the obvious extensions here.

 

FWIW mingw-w64 fixed this, and it was far from difficult. Here we use .dll.a and .a.

 

I appeal to the CMake moderators to consider the damage this situation causes to the genericness and hygiene of CMakeList.txt files.

 

On Sat, May 19, 2018, 2:00 PM Elvis Stansvik <[hidden email]> 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. Note that the above was just an example.
But many packagers do it like this.

How can I make life easier for the packager?

I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
add_library(...), one with SHARED and one with STATIC, but the same
input source files. I could give the two libraries different output
filenames, as to not conflict on e.g. Windows (where I think the .lib
import library containing symbols for the .dll would otherwise
conflict with the static library .lib, or..?).

To not have to repeat the list of sources, I could keep them in a
variable. But that's not recommended in modern CMake AFAIK.

I've also seen people add an object library, and then build the shared
+ static lib from that.

What are your thoughts on all this? How do you go about it? Do you use
the recommended way, with a single add_library(..) and just let
packagers put up with having to do two builds?

Thanks in advance!
Elvis
--

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
Reply | Threaded
Open this post in threaded view
|

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

Mateusz Loskot
In reply to this post by Ray Donnelly
On 19 May 2018 at 22:16, Ray Donnelly <[hidden email]> wrote:

> On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <[hidden email]> wrote:
>> On 19 May 2018 at 15:00, Elvis Stansvik <[hidden email]> 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.

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
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

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

Ray Donnelly


On Sat, May 19, 2018, 9:38 PM Mateusz Loskot <[hidden email]> wrote:
On 19 May 2018 at 22:16, Ray Donnelly <[hidden email]> wrote:
> On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <[hidden email]> wrote:
>> On 19 May 2018 at 15:00, Elvis Stansvik <[hidden email]> 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

--

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
Reply | Threaded
Open this post in threaded view
|

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

Mateusz Loskot
I understand your

Mateusz Loskot, [hidden email]
(Sent from mobile)

On Sat, 19 May 2018, 22:54 Ray Donnelly, <[hidden email]> wrote:
On Sat, May 19, 2018, 9:38 PM Mateusz Loskot <[hidden email]> wrote:
On 19 May 2018 at 22:16, Ray Donnelly <[hidden email]> wrote:
> On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <[hidden email]> wrote:
>> On 19 May 2018 at 15:00, Elvis Stansvik <[hidden email]> 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 



--

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
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

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

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, [hidden email]
(Sent from mobile)

On Sun, 20 May 2018, 00:03 Mateusz Loskot, <[hidden email]> wrote:
I understand your

Mateusz Loskot, [hidden email]
(Sent from mobile)

On Sat, 19 May 2018, 22:54 Ray Donnelly, <[hidden email]> wrote:
On Sat, May 19, 2018, 9:38 PM Mateusz Loskot <[hidden email]> wrote:
On 19 May 2018 at 22:16, Ray Donnelly <[hidden email]> wrote:
> On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <[hidden email]> wrote:
>> On 19 May 2018 at 15:00, Elvis Stansvik <[hidden email]> 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 



--

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
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

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

Elvis Stansvik
In reply to this post by Mateusz Loskot
2018-05-19 21:49 GMT+02:00 Mateusz Loskot <[hidden email]>:

> On 19 May 2018 at 15:00, Elvis Stansvik <[hidden email]> 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), 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
Reply | Threaded
Open this post in threaded view
|

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

Ray Donnelly
On Sat, May 19, 2018 at 11:55 PM, Elvis Stansvik
<[hidden email]> wrote:

> 2018-05-19 21:49 GMT+02:00 Mateusz Loskot <[hidden email]>:
>> On 19 May 2018 at 15:00, Elvis Stansvik <[hidden email]> 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.

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

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
Reply | Threaded
Open this post in threaded view
|

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

Elvis Stansvik
2018-05-20 4:19 GMT+02:00 Ray Donnelly <[hidden email]>:

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

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