cmake: Introduce Libmultiprocess_INSTALL_PKGCONFIG_FILE build option

[hebasto]

This PR makes the installation of the pkgconfig/libmultiprocess.pc file optional.

[hebasto]

Also, the pkgconfig subdirectory seems redundant here, no?

[fanquake]

Is there a particular reason to not install it by default? Note that pkg-config is just a generic tool, and it's usage is not specific to Autotools. Meson and other build systems also use it.

[hebasto]

Is there a particular reason to not install it by default? Note that pkg-config is just a generic tool, and it's usage is not specific to Autotools. Meson and other build systems also use it.

The default value of the new option has been changed to ON.

[ryanofsky]

What's the motivation for this change? It seems like an unusual thing for a package to have a configuration option to not fully install itself. And if installing a .pc file is optional, should installing .cmake package files be optional also? I think I'd prefer the cmake code here to be as vanilla as possible and not have a non-standard option like this, unless there is a real reason why it's useful.

Also it seems would seem better to just use cmake components to control what is installed instead of using both cmake components and cmake options to control what is installed. Maybe installed metadata files could be moved into different components to provide finer-grained control over what to install if this is necessary.

[hebasto]

What's the motivation for this change?

Currently, the package built in Bitcoin Core depends looks like that:

$ tree
.
├── include
│   └── mp
│       ├── proxy.capnp.h
│       ├── proxy.h
│       ├── proxy-io.h
│       ├── proxy-types.h
│       └── util.h
└── lib
    ├── cmake
    │   └── Libmultiprocess
    │       ├── LibmultiprocessConfig.cmake
    │       ├── LibTargets.cmake
    │       └── LibTargets-noconfig.cmake
    ├── libmultiprocess.a
    └── pkgconfig
        └── libmultiprocess.pc

7 directories, 10 files

The pkgconfig/libmultiprocess.pc file is not needed. Alternatively, it can be deleted during postprocessing, as we do with other packages.

[sedited]

Alternatively, it can be deleted during postprocessing, as we do with other packages.

I think I would prefer that.