Any particular reason not to install CMake configs in static mode?

[HappySeaFox]

Currently, avif installs CMake configs only in SHARED mode. But do we really have any particular reason not to install CMake configs in static mode?

If I re-enable installing CMake configs in static mode (by simply commenting out if (BUILD_SHARED_LIBS) at line 567), they are generated, installed, and used OK by a client application.

This prevents, for example, vcpkg integration from working correctly.

[joedrago]

The intent of the install step in our current CMake rules is to install shared libraries on "the system" alongside its dependent shared libraries (the AV1 implementations such as libaom, dav1d, etc). In this kind of environment, statically linking in libraries that could be shared and updated independently (for perf or security reasons) is typically frowned on, so I didn't consider it as a use case.

I didn't realize vcpkg was a legal destination for a CMake install routine, and am not a user of it. If you can come up with a vcpkg-specific (checking for things like WIN32, say) set of changes to allow for such a static install path to unblock your vcpkg install, I'd certainly review the PR. Are there already vcpkgs for static builds of libaom, dav1d, etc? Can there be a libavif static library build that would play nicely with such a thing? I don't want to support static library installs (in which AV1 impls are baked in) on all platforms, but if this is the typical vcpkg path, I don't see why we couldn't add support specifically for this.

[HappySeaFox]

vcpkg installs static libs on OSX and Linux. On Windows there are two options: static and dynamic.

Are there already vcpkgs for static builds of libaom, dav1d, etc?

Yes for AOM (microsoft/vcpkg#18083). No for dav1d currently because of the vcpkg issue (microsoft/vcpkg#16986)

You can detect the vcpkg mode by checking any of the vcpkg CMake vars. For example, vcpkg sets VCPKG_TARGET_TRIPLET CMake var. Cache:

//Vcpkg target triplet (ex. x86-windows)
VCPKG_TARGET_TRIPLET:STRING=x64-windows

I'd certainly review the PR

Sure, let's do it!

Can there be a libavif static library build that would play nicely with such a thing?

Yes, it can. It's almost there microsoft/vcpkg#18244 . I was able to compile and run a small test application against the static libavif from vcpkg on Linux. I guess it works fine for all use-cases.

[HappySeaFox]

Merged, I guess you can close the issue?

[wantehchang]

Hi Dmitry,

Just wanted to confirm that you want us to close this issue, right?

[HappySeaFox]

Right 😊 пн, 7 июн. 2021 г., 05:26 Wan-Teh Chang ***@***.***>:

…

Hi Dmitry, Just wanted to confirm that you want us to close this issue, right? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#658 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGDS3XKZQIKVWR4BRBENDTTRQU4DANCNFSM457D4GCA> .

[wantehchang]

Thanks. I closed the issue.

I am surprised that the website does not let you close an issue you filed.