build, depends: Fix `libmultiprocess` cross-compilation #29665

On the master branch @ 3b12fc7bcd94cf214984911f68612feb468d5404, the following command fails:

$ make -C depends libmultiprocess HOST=arm64-apple-darwin MULTIPROCESS=1
...
[100%] Linking CXX executable mpgen
...
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
...

This PR prevents building all default targets that include mpgen, which expectedly fails to link when cross-compiling.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage

For detailed information about the code coverage, see the test coverage report.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

cc @ryanofsky

As an alternative, the mpgen target might be disabled when cross-compiling in the upstream build system.

Code review ACK 178065f27d2852c9ec7c5f44ab2c26c0d092bf70

Thanks for the fix. I don't actually understand why the fix is needed, when this was broken, or why mpgen linking should fail when it is cross compiled. That seems like an upstream bug and it would be nice to have more information about it, though the workaround here seems acceptable and has some nice features like being more efficient and using separate source/build directories.

There are some things I don't like about the workaround, but I don't think they are too important:

• I don't think it's great that is now hardcoding multiprocess and mpgen target names into the build script instead of relying on the fact that install-lib and install-bin targets will automatically build the targets that are needed. For example now if an another helper library is added upstream or one of the targets is renamed, the install commands will fail because the right targets will not have been built.
• I think it would be better if the build and install logic remained upstream instead of being moved into the depends build. If it is important to be able to separate build and install steps, we could add new "bin" and "lib" targets upstream to complement existing "install-bin" and "install-lib" targets.
• I think it would be nice if other cleanups in this PR were separate commits so all the changes would be easy to understand.
• I don't understand the "Rebuilding during installation has been skipped." comment, because I would not think anything would have been actually been built during the install step if make was just run previously.

But again these are all minor concerns and this looks good to merge in its current form (probably with 1 other ACK)

• I don't understand the "Rebuilding during installation has been skipped." comment, because I would not think anything would have been actually been built during the install step if make was just run previously.

Consider the following commands in the libmultiprocess root directory:

$ cmake .
$ make
$ make DESTDIR=/home/hebasto/INSTALL install-lib
Consolidate compiler generated dependencies of target util
[ 20%] Built target util
Consolidate compiler generated dependencies of target multiprocess
[100%] Built target multiprocess
-- Install configuration: ""
-- Install component: "lib"
-- Installing: /home/hebasto/INSTALL/usr/local/lib/libmultiprocess.a
-- Installing: /home/hebasto/INSTALL/usr/local/include/mp/proxy.capnp.h
-- Installing: /home/hebasto/INSTALL/usr/local/include/mp/proxy-io.h
-- Installing: /home/hebasto/INSTALL/usr/local/include/mp/proxy-types.h
-- Installing: /home/hebasto/INSTALL/usr/local/include/mp/proxy.h
-- Installing: /home/hebasto/INSTALL/usr/local/include/mp/util.h
-- Installing: /home/hebasto/INSTALL/usr/local/lib/pkgconfig/libmultiprocess.pc
-- Installing: /home/hebasto/INSTALL/usr/local/lib/cmake/libmultiprocess-lib.cmake
-- Installing: /home/hebasto/INSTALL/usr/local/lib/cmake/libmultiprocess-lib-noconfig.cmake
[100%] Built target install-lib

From the build log it follows that the util and multiprocess targets were being rebuilt.

That's not the case when using cmake --install ... command.

From the build log it follows that the util and multiprocess targets were being rebuilt.

I don't think that's true. I see lines like Building CXX object CMakeFiles/util.dir/src/mp/util.cpp.o and Linking CXX static library libmultiprocess.a when targets are actually being built and lines like Built target util and Built target multiprocess when targets were previously built. Running make install-bin or make install-lib after building shouldn't cause anything to be rebuilt unless sources have changed. So I think the comment "Rebuilding during installation has been skipped" might be inaccurate, and that you could revert the change switching "make install-lib" and "make install-bin" to cmake --install --component ..., although neither of these things are too important.

OK. I've dropped all unrelated / unneeded changes.

Code review ACK 2de2ea2ff63b97eacb23234932c6e1f1f65e4494

Maybe @fanquake would be a good second reviewer

OK. I've dropped all unrelated / unneeded changes.

That's reasonable, and the change is very simple now. To be clear, I wasn't asking for anything to be reverted, and I'm fine with any version of this PR. I'm mostly curious to know why a link error even happens at all. But I guess can download the mac sdk to experiment. Thanks for the fix and information about this.

ACK 2de2ea2ff63b97eacb23234932c6e1f1f65e4494 - I checked that this fixes the macOS cross-compilation issue. I'm assuming these packages are also likely to change further in the (near) future, given the changes going in upstream: https://github.com/chaincodelabs/libmultiprocess/pulls?q=is%3Apr+is%3Aclosed.

I don't actually understand why the fix is needed, when this was broken, or why mpgen linking should fail when it is cross compiled.

I agree with Russ that it'd be better to actually figure out what the root cause is, and fix it more directly, rather than working around it just to make things compile.