Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable Users to Opt-In to Building Catch2 as a Shared Library #2397

Closed
codeinred opened this issue Mar 23, 2022 · 5 comments
Closed

Enable Users to Opt-In to Building Catch2 as a Shared Library #2397

codeinred opened this issue Mar 23, 2022 · 5 comments
Labels
Building and Packaging Issues affecting build/packaging scripts and utilities

Comments

@codeinred
Copy link
Contributor

codeinred commented Mar 23, 2022

Description
Build times when tend to be much faster when linking against a shared library as compared to linking against a statically linked library. These improved build times allow for faster iteration on projects and a smoother development experience.

Right now, Catch2 can only be built as a statically linked library, even when -DBUILD_SHARED_LIBS=ON is passed to CMake.

Changes required
Remove STATIC declaration when invoking add_library for Catch2 and Catch2WithMain

Impact on Existing Code
Little to none. Catch2 will continue to build statically linked by default.

@Finii
Copy link

Finii commented Apr 5, 2022

Interesting. I never noticed linking against a dynamic lib to be faster. Which platform are you on? Do you have any benchmarks to share that show the speedup?

Thank you, Fini

@cpreh
Copy link

cpreh commented Jun 12, 2022

Linking statically with Catch produces huge binaries (around 1.1MiB per binary). After I migrated to version 3.0.1. the size of all of my build directories went up by about 15GiB in total. In previous versions (where you had to compile Catch inside your project) you were at least able to create a shared library. This ability is now completely gone and makes Catch basically unusable to me in its current form.

@Finii
Copy link

Finii commented Jun 12, 2022

... around 1.1MiB per binary... about 15GiB in total

Wow. 13600 binaries! Not bad 👍

@cpreh
Copy link

cpreh commented Jun 12, 2022

I do have around 1300 binaries that link against Catch and I have different configurations that I test (i.e. different compilers, settings, etc.). All in all this is just a rough estimate.

@cpreh
Copy link

cpreh commented Jun 12, 2022

I just changed "STATIC" to "SHARED" in Catch to reclaim my disk space for the time being.

As somebody noted in the CMakeLists file, doing a shared library "requires" annotating C++ functions/globals to declare their visibility. This is a good idea in general because Linux binaries can also benefit from this (using -fvisibility=hidden).
However, a quick and easy way to produce a shared library that doesn't require annotations is to set the target property CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS.

I'm hoping that this will find its way into an official release in some way or another.

@horenmar horenmar added the Building and Packaging Issues affecting build/packaging scripts and utilities label Jun 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Building and Packaging Issues affecting build/packaging scripts and utilities
Projects
None yet
Development

No branches or pull requests

4 participants