randombit
botan-config.cmake: Hard-code installation paths?
TL;DR: Does the botan-config.cmake file need to remain relocatable (via installation directory structure guesswork)? Or could we simplify it by hard-coding the installation paths that our build system dictates (configurable via ./configure.py --prefix --libdir --includedir ...)?
The cmake config file (originally added two years ago) is starting to collect complexity because it tries to be compatible to as many platforms and package managers as possible (1, 2) while maintaining relocatability. Right now, botan-config.cmake is based on a heuristic to find the library's include and library files based on the location of botan-config.cmake itself. This makes the whole installation relocatable (from the cmake config file's perspective that is). For that, it has to actively handle systems that use a target triplet in their library path, or systems that use lib64 instead of lib. On Windows is has to actively find the .lib file accompanying the .dll. I'm sure there are more scenarios where this falls short. And we also don't test all the scenarios we support, so regressions are likely.
Alternatively, we could ditch relocatability (3) and simply render the botan-config.cmake file using the installation path information configure.py provides. The artefact installation locations can be controlled via --prefix, --libdir, --includedir, and perhaps --bindir. botan-config.cmake would then contain an exact set of artefact installation paths tailored to the configured setup without trying to handle all possible configurations found in the wild.
Of course, this assumes that distribution package maintainers actually use those configure.py switches and not just move things in place manually after installing to default locations. Perhaps @thesamesam, @carlosrodfern could provide some input here?
The natively-generated packaging files cmake produces if it is used to install a library are only relocatable in the sense that you can atomically move the entire set of installed files to a different location on the filesystem and everything still works, but moving the files around relative to each other post-installation is not expected to work.
No end user who is consuming Botan using cmake is going to complain if Botan's cmake packaging files behave the same way as natively-generated cmake files would.
Some platforms have different conventions about where botan-config.cmake should be located relative to the installation prefix so if that was configurable then distribution maintainers would have no reason to move files manually post-install and break the paths.
