Fails to build as shared library on osx (via vcpkg)

[m-kuhn]

ERROR: Unbound var 'implib_name' in template /Users/mkuhn/dev/vcpkg/buildtrees/botan/src/3.3.0-c527fba307.clean/src/build-data/botan-config.cmake.in

Tentative patch:

diff --git a/configure.py b/configure.py
index 3535757..d767e76 100755
--- a/configure.py
+++ b/configure.py
@@ -2341,6 +2341,8 @@ def create_template_vars(source_paths, build_paths, options, modules, disabled_m
 
         if options.os == 'windows':
             variables['implib_name'] = variables['static_lib_name']
+        else:
+            variables['implib_name'] = variables['libname']
 
         variables['lib_link_cmd'] = variables['lib_link_cmd'].format(**variables)

I couldn't verify because I'm running into Apple Clang 14 limitations in a subsequent build step which I don't think is a botan issue but more a build chain / Apple issue.

In file included from /Users/mkuhn/dev/vcpkg/buildtrees/botan/src/3.3.0-34fb5dbab4.clean/src/lib/asn1/asn1_str.cpp:10:
In file included from build/include/public/botan/ber_dec.h:13:
In file included from build/include/public/botan/mem_ops.h:11:
build/include/public/botan/concepts.h:51:54: error: no template named 'range_value_t' in namespace 'std::ranges'
template <typename T, typename ValueT = std::ranges::range_value_t<T>>

https://stackoverflow.com/questions/74679839/stdrangesany-of-fails-when-compiling-with-apple-clang-14-0

[randombit]

I'm not familiar with the CMake support so I'm not sure about your fix. I think it works but doesn't seem quite right - the relevant bit of the template code is

%{if implib_name}
set(_Botan_implib     "${_Botan_PREFIX}/lib/%{implib_name}")
set(_Botan_shared_lib "${_Botan_PREFIX}/bin/%{shared_lib_name}")
%{endif}
%{unless implib_name}
set(_Botan_implib "")
%{endif}

Since every usage is either a conditional or guarded by the conditional I don't see why it would be unbound at any point. @reneme any ideas? Are we only testing CMake support on Windows possibly? Also I think the import lib is really just a Windows notion and isn't sensible to speak of for Linux/mac/etc.

Regarding compiler versions - unfortunately we require at least XCode 15. While for GCC/Clang/MSVC, we fixed a minimum supported compiler version with the release of 3.0.0, and seek to maintain that through the lifetime of Botan 3, we did not do so for XCode largely because at the time of 3.0.0, XCode was quite behind what is supported even in GCC 11, so the minimum supported version of XCode is left floating. At this point I don't think XCode (at 15.2) is holding us back, so we can probably consider freezing on that as our minimum going forward.

Also unfortunately, until (the upcoming/currently unreleased) Botan 3.5.0, the build system didn't distinguish LLVM Clang and XCode Clang. Since we support LLVM Clang 14 just fine, the configure.py script doesn't notice that you're compiling with a compiler that we don't support. The configure.py script checks this and normally will just stop if it detects this condition.

[randombit]

BTW if you're not relying on/using the CMake support, you can use --without-cmake-config to disable this entirely.

[m-kuhn]

This comes from vcpkg which is heavily built around cmake, having a proper cmake config exported is a plus in this scenario.

[randombit]

Makes sense.

Oddly I can't replicate this with either 3.3.0 or master on a Linux machine (which likewise doesn't have the notion of an import library)

I wonder if VCpkg is shipping with some patch...

[randombit]

Oh goody VCpkg is shipping with all kinds of patches

https://github.com/microsoft/vcpkg/tree/master/ports/botan

including

https://github.com/microsoft/vcpkg/blob/master/ports/botan/fix-cmake-usage.patch

which seems to be at fault here.

@reneme can you see what if anything from fix-cmake-usage.patch is worth adopting?

@m-kuhn this seems to be a VCpkg specific issue, you'll have to take it up with them. We generally aim to make it so that distributors do not need to patch us (because it usually goes poorly, as here) potentially we can get this addressed in the next release so that they don't feel the need to do this anymore.

[m-kuhn]

@randombit thank you for going down that rabbit hole. I actually had a look at the patches myself and somehow that escaped my attention.
I'll follow up with a patch there.
Sorry for the noise!

I'll leave this open for the question about adapting (parts of) fix-cmake-usage.patch raised above, feel free to close it anytime.

[dg0yt]

FTR vcpkg creates combined release+debug installations (aka multi-config). That's one driver for patches, and in this is also the case for cmake config files from Botan.

[reneme]

can you see what if anything from fix-cmake-usage.patch is worth adopting?

From what I understand, the fix-cmake-usage.patch is mostly necessary to support multi-config installations, as @dg0yt said. I'm not familiar with the inner workigns of vcpkg unfortunately. Though, I'm guessing, that they are building botan twice (once w/ --debug-mode and once w/o, and with different install prefixes) and then use the patched cmake config to bind it all together. I.e. that appears tailored for the concrete vcpkg use case and isn't easily applied upstream.

That said: perhaps we could provide a multi-config debug/release build mode in configure.py to handle this exact use case. Or: find someone to fund a CMake-based build system rewrite. 😇

[dg0yt]

Splitting CMake config in two files (general and per build-type; following the CMake pattern) would be a small change which could be developed/tested in vcpkg and upstreamed. This might still be somewhat specific to vcpkg but could be adapted more easily by others (conan?)

[reneme]

This sounds like a good idea. Do you happen to have a pointer to some CMake documentation that explains this pattern?

Regarding Conan: to the best of my understanding, conan prefers to generate those config files themselves (via their CMakeDeps generator) instead of using library-specific ones. Their claim is, that multi-config IDEs would otherwise not work properly due to a CMake limitation.

[BillyONeal]

can you see what if anything from fix-cmake-usage.patch is worth adopting?

From what I understand, the fix-cmake-usage.patch is mostly necessary to support multi-config installations, as @dg0yt said. I'm not familiar with the inner workigns of vcpkg unfortunately. Though, I'm guessing, that they are building botan twice (once w/ --debug-mode and once w/o, and with different install prefixes) and then use the patched cmake config to bind it all together. I.e. that appears tailored for the concrete vcpkg use case and isn't easily applied upstream.

That said: perhaps we could provide a multi-config debug/release build mode in configure.py to handle this exact use case. Or: find someone to fund a CMake-based build system rewrite. 😇

I interpreted this statement as 'we'd like to do it but aren't sure how right now but don't object to the way it's done in the vcpkg patch', so I merged @m-kuhn 's patch there. Thanks!

[randombit]

Closing as I think there is nothing more that is immediately actionable here