Install Exports for custom `install-{lib,bin}` targets #79

This is a follow up of chaincodelabs/libmultiprocess#74 and addresses https://github.com/chaincodelabs/libmultiprocess/pull/74#pullrequestreview-1106150689:

The only downside of the current implementation is that new install-lib and install-bin targets do not export the underlying targets.

Can confirm neither of the new install commands create $PREFIX/cmake/Multiprocess/Multiprocess.cmake and $PREFIX/lib/cmake/Multiprocess/Multiprocess-debug.cmake files.

Probably should update install() EXPORT Multiprocess arguments to EXPORT libmultiprocess-bin and EXPORT libmultiprocess-lib so the two installs can be independent. And maybe there is a way to get the new install-bin and install-lib commands to actually export these targets.

Thanks for following up. I think PR is an improvement over status quo, but I suggested a few tweaks that might make it better.

Additionally, it could be good to add NAMESPACE Libmultiprocess:: to install commands to scope exported targets under the cmake project name.

Later, it might also be good to turn the install into a full cmake package (https://cmake.org/cmake/help/latest/guide/importing-exporting/index.html#creating-a-package-configuration-file) so if a bitcoin cmake build is added, it could use find_package instead of include and take advantage of cmake package detection & versioning features.

Updated 78bfa2a2812fe56b172ca4f16e7c332d0e03f103 -> d795e969dd7c913c937a4f97d78115072feb6cb4 (pr79.01 -> pr79.02):

• rebased
• addressed @ryanofsky's comments

Additionally, it could be good to add NAMESPACE Libmultiprocess:: to install commands to scope exported targets under the cmake project name.

Done.

Later, it might also be good to turn the install into a full cmake package (https://cmake.org/cmake/help/latest/guide/importing-exporting/index.html#creating-a-package-configuration-file) so if a bitcoin cmake build is added, it could use find_package instead of include and take advantage of cmake package detection & versioning features.

FWIW, here is a branch with a proof of concept -- https://github.com/hebasto/libmultiprocess/commits/230128-export.DEMO.

And here is its use case -- https://github.com/hebasto/bitcoin/commits/230128-cmake.MP.DEMO.

The problem to be solved is the handling of all dependencies (capnp, kj etc) via config files...

Reviewed dae3ff8827e4803f601c764ac4664815b14251b9 and confirmed that install-bin and install-lib now lib/cmake/libmultiprocess-bin.cmake and lib/cmake/libmultiprocess-bin.cmake files respectively, containing exported targets from the project. The only thing I think it would be good to do still is make the target namespace name libmultiprocess the same as the cmake project name Libmultiprocess.

Updated dae3ff8827e4803f601c764ac4664815b14251b9 -> 2dda7536b5f4192de0fc06c16157f1ad90f5d762 (pr79.03 -> pr79.04, diff):

• addressed @ryanofsky's comment

Code review ACK 2dda7536b5f4192de0fc06c16157f1ad90f5d762. Only change since last review is changing namespace prefix to match project name as suggested (thanks!)

Just to follow up, it turns out this change caused two regressions:

1 - A problem in the bitcoin core "depends" build when the bitcoin core autoconf script could not find the libmultiprocess.pc file because it was installed to "lib64" not "lib" (https://github.com/chaincodelabs/libmultiprocess/pull/79#discussion_r1399049836). This was fixed in depends in https://github.com/bitcoin/bitcoin/pull/28846.

2 - A second problem fixed in #90 where the libmultiprocess.pc points to "lib" not 'lib64" resulting in link errors when the libmultiprocess libary is installed in "lib64" and can't be found. The fix for the previous problem masked this issue in the depends build by making the depends build always install to "lib." But outside of the depends build, link errors could still happen. #90 fixes the problem by updating libmultiprocess.pc to point to the correct location.