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

Do not require dependencies for static linking when exiv2 was built as shared #2872

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

pinotree
Copy link
Contributor

exiv2 can be built either as shared library, or static, never both at the same time. Hence, requiring the dependencies needed for static linking to exiv2 when exiv2 was built shared does not make much sense, and it only adds unneeded bits to the exiv2 users.

Hence, fix both the pkg-config file, and the cmake config file, to require the dependencies needed for static linking only in case exiv2 was built as static library. This avoids e.g. having the expat and zlib development bits when using exiv2 in cmake with find_package(exiv2).

See the specific commit messages for longer descriptions.

Commit 63f9926 exports the dependencies
for static linking to the pkg-config file. There are two problems with
the implementation:
- "Requires.private" in the pkg-config file makes the pkg-config
  implementation require the specified modules, even when not building
  statically
- the exiv2 library build is done either shared or static, so there is
  no static library in case of a shared build

Hence, output the dependencies for the static linking in the pkg-config
file only when the exiv2 library build is not shared (i.e. static).
Commit a8c3455,
commit 5e1cf4d, and
commit 4dfb781 implement & add the
libraries needed in case of static linking as dependencies for the cmake
config file. There are two problems with the implementation:
- being unconditionally there, they will make those modules required
  when building against exiv2, even when not building statically
- the exiv2 library build is done either shared or static, so there is
  no static library in case of a shared build

Hence, require the dependencies for the static linking in the cmake
config file only when the exiv2 library build is not shared (i.e.
static).
@ghost
Copy link

ghost commented Dec 27, 2023

👇 Click on the image for a new way to code review

Review these changes using an interactive CodeSee Map

Legend

CodeSee Map legend

Copy link

codecov bot commented Dec 27, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (b4f145e) 63.89% compared to head (a1ff128) 63.89%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2872   +/-   ##
=======================================
  Coverage   63.89%   63.89%           
=======================================
  Files         103      103           
  Lines       22381    22381           
  Branches    10872    10872           
=======================================
  Hits        14301    14301           
  Misses       5857     5857           
  Partials     2223     2223           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@kmilos
Copy link
Collaborator

kmilos commented Dec 30, 2023

Some distros ship both static and shared libs, how would you handle that? We still need a single .pc file that handles both. If you don't pass --static to pkg-config there is no harm done, no?

@pinotree
Copy link
Contributor Author

Some distros ship both static and shared libs,

Do you have examples of this? I checked Arch, Debian (which I maintain) and thus Ubuntu, Fedora, FreeBSD, Gentoo, Mageia, OpenBSD, openSUSE, Void, and other distros are derivatives of the ones mentioned (thus sharing the build configuration). All of the ones I inspected build using the default built type, which is shared, and no static bits are shipped (with the exception of libexiv2-xmp.a, gone in 0.28).

From what I can see (I also mentioned that in my commit messages), you can build only one variant at a time with cmake, and most likely the same with meson. Hence, if the situation you mention must be supported somehow, then I need to see exactly how and what for.

@eli-schwartz
Copy link
Contributor

From what I can see (I also mentioned that in my commit messages), you can build only one variant at a time with cmake, and most likely the same with meson.

No, meson has always supported building both at the same time, and it does this quite well.

This is vital for cross-platform support since unix platforms frequently need this, and it works quite well there. It doesn't work quite so well on Windows (you either need to use .def files or compile every object twice, and then import libraries and static libraries both frequently use .lib) which is usually "this is fine" because on Windows you have to build private copies of your entire dep tree without benefit of a package manager.

And since CMake was primarily designed to work well on Windows, it assumes the Windows model and doesn't bother to support meson -Ddefault_library=both / autotools "--enable-static --enable-shared".

Distros such as Alpine and Debian often package both, when the build system supports both, but won't necessarily go out of their way to run cmake twice in order to build and install both.

@kmilos
Copy link
Collaborator

kmilos commented Dec 31, 2023

won't necessarily go out of their way to run cmake twice in order to build and install both

OTOH, we frequently do run CMake twice on MSYS2 and install both artifacts.

@eli-schwartz
Copy link
Contributor

Very true, MSYS2 has a somewhat stronger motivation to provide both.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants