cmake: Combine installed packages #98

This change combines previous installed:

• cmake/LibmultiprocessLibConfig.cmake
• cmake/LibmultiprocessBinConfig.cmake

files into a single:

• cmake/Libmultiprocess/LibmultiprocessConfig.cmake

file, so it can be imported with find_package(Libmultiprocess).

The previous locations which were set in https://github.com/chaincodelabs/libmultiprocess/pull/97 were not compatible with find_package search behavior by default.

The change also adds some documentation about using the new package to doc/install.md.

Other comments about this

https://github.com/chaincodelabs/libmultiprocess/pull/97#issue-2216115039 https://github.com/chaincodelabs/libmultiprocess/pull/95#issuecomment-2027918956 https://github.com/chaincodelabs/libmultiprocess/pull/97#issuecomment-2027937177 https://github.com/chaincodelabs/libmultiprocess/pull/95#issuecomment-2028113800 https://github.com/chaincodelabs/libmultiprocess/pull/97#issuecomment-2030360238

I did not test this PR yet, but have a question regarding the combined package configuration.

In the Bitcoin Core depends, how does it suppose to work considering that the mpgen tool is installed in the native subdirectory of the depends prefix?

I'm not sure exactly, but I'd imagine you'd just find the package twice with different components instead of finding two packages separately. Even before this PR you would need to point cmake at the native directory to find the code generation package, so I don't think that aspect is changing.

Or if the issue is that cmake doesn't allow importing two packages with the same name, maybe a good solution would be to add an option here controlling the installed package name.

If multiple libmultiprocess builds are installed (native and cross-compiled) it seems good if they are all allowed to be full installs, and downstream cmake projects can choose which components of each install to use. Even though depends system only does half-builds for efficiency (executable only or library only), this doesn't seem like something that should be required for other builds.

I'm not sure exactly, but I'd imagine you'd just find the package twice with different components instead of finding two packages separately.

Once a package found, the ${PACKAGE}_DIR variable is cached.

Therefore, to work with Bitcoin Core's depends, the code as follows should be used:

find_package(Libmultiprocess COMPONENTS Lib)
unset(Libmultiprocess_DIR CACHE)
find_package(Libmultiprocess COMPONENTS Bin
  NO_CMAKE_FIND_ROOT_PATH
  PATHS ${CMAKE_FIND_ROOT_PATH}/native
)

But this approach undermines the user's ability to specify non-standard package component locations because the Libmultiprocess_DIR variable is overloaded.

Or if the issue is that cmake doesn't allow importing two packages with the same name, maybe a good solution would be to add an option here controlling the installed package name.

If such an option will be leveraged by depends, Bitcoin Core probably will fail to find the Libmultiprocess package provided by other means.

re: https://github.com/chaincodelabs/libmultiprocess/pull/98#issuecomment-2241236657 @hebasto can you use the find_package NAMES option to give the packages different names? From the find_package documentation:

A cache entry called <PackageName>_DIR is created to hold the directory containing the file. By default, the command searches for a package with the name <PackageName>. If the NAMES option is given, the names following it are used instead of <PackageName>.

So modifying your example above, you could write:

find_package(Libmultiprocess COMPONENTS Lib)
find_package(LibmultiprocessNative COMPONENTS Bin
  NAMES Libmultiprocess
  NO_CMAKE_FIND_ROOT_PATH
  PATHS ${CMAKE_FIND_ROOT_PATH}/native
)

This should result in separate Libmultiprocess_DIR and LibmultiprocessNative_DIR variables

@ryanofsky

can you use the find_package NAMES option to give the packages different names? From the find_package documentation:

Thank you! The suggested approach looks nice to me.

It only requires a bugfix suggested in https://github.com/chaincodelabs/libmultiprocess/pull/103.