Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmake: Add MULTIPROCESS option #118

Merged
merged 3 commits into from
Apr 8, 2024
Merged

cmake: Add MULTIPROCESS option #118

merged 3 commits into from
Apr 8, 2024

Conversation

hebasto
Copy link
Owner

@hebasto hebasto commented Mar 9, 2024

Also a new "Linux 64-bit, multiprocess" CI task has been added.

Also see: bitcoin#29665.

Copy link

@pablomartin4btc pablomartin4btc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cr ACK a08579d

  • New CI added as mentioned in description;
  • Setting multiprocess option ON;
  • Added new macro generate_from_capnp in cmake/module/GenerateMPCode.cmake;
  • Added new CMakeLists.txt for IPC directory;
  • Added new IPC library into linking for bitcoin-gui targets when multiprocess is enabled.

Doc reference for multiprocess and IPC.

Other than that, new CI is running successfully:

image

Where in the CI details can be seeing the multiprocess optional package enabled in the configuration summary (Generate build system task):

...

Optional packages:
  GUI ................................. Qt5
  external signer ..................... ON
  multiprocess ........................ ON
...

@hebasto
Copy link
Owner Author

hebasto commented Mar 11, 2024

@ryanofsky

You may also be interested in this PR :)

Copy link

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review ACK a08579d.

Seems like a nice change. I do agree with the "TODO: Switch to find_package() command" comment. It would be nice to avoid using pkgconfig and ideally find the package using the ${libdir}/cmake/libmultiprocess-*.cmake files that are installed.

cmake/module/GenerateMPCode.cmake Outdated Show resolved Hide resolved
src/ipc/CMakeLists.txt Outdated Show resolved Hide resolved
@hebasto
Copy link
Owner Author

hebasto commented Mar 11, 2024

I do agree with the "TODO: Switch to find_package() command" comment. It would be nice to avoid using pkgconfig and ideally find the package using the ${libdir}/cmake/libmultiprocess-*.cmake files that are installed.

Unfortunately, those target import files do not propagate dependency targets. As such, they have to be handled separately which increases complexity.

@hebasto
Copy link
Owner Author

hebasto commented Mar 11, 2024

@ryanofsky

Thank you for your valuable review!

I've reworked the branch basing on your suggestion. Now it looks much cleaner :)

Copy link

@pablomartin4btc pablomartin4btc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re ACK 8e739cd

Addressed @ryanofsky's feedback since my last review, mainly replacing macro generate_from_capnp capnp_relpath by function target_capnp_sources.

Copy link

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review ACK 8e739cd

re: #118 (comment)

Unfortunately, those target import files do not propagate dependency targets. As such, they have to be handled separately which increases complexity.

Hmm, what does this mean specifically? It seems like the installed cmake files are calling add_library and add_executable to add targets and setting the needed properties. Does something need to be improved in https://github.com/chaincodelabs/libmultiprocess/blob/master/CMakeLists.txt, because current install(EXPORT...) lines are not enough?

cmake/module/GenerateMPCode.cmake Outdated Show resolved Hide resolved
set(MULTIPROCESS ON CACHE STRING "")
endif()
if(NOT MPGEN_PREFIX)
set(MPGEN_PREFIX "${CMAKE_FIND_ROOT_PATH}/native" CACHE PATH "")
Copy link

@ryanofsky ryanofsky Mar 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really understand what this is doing, might be helpful to add a comment. Particularly what is the last "" argument?

EDIT: I guess last "" arguments are for documentation? Are these arguments actually required? If they are it seems like it would be helpful to change them to something like "Set by depends build" to document where they are coming from

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This command uses the following signature:

set(<variable> <value>... CACHE <type> <docstring> [FORCE])

where the <docstring> is mandatory. It allows the user to override its value with -DMPGEN_PREFIX=... in the command line.

What about "libmultiprocess codegen tool prefix"?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about "libmultiprocess codegen tool prefix"?

Well "libmultiprocess codegen tool prefix" already seems to be the documentation string for this option in cmake/optional.cmake so that seems very good.

But I'm confused about why any documentation string is required at all in depends/toolchain.cmake.in which should just be overriding values, not defining new options. If I understand https://cmake.org/cmake/help/latest/command/set.html correctly, in-memory values naturally override cached values, so it seems like the ideal thing would be to stop specifying CACHE <type> <docstring> arguments in this file, and just set the values in memory. If writing the cache here really is necessary though, I'd think appropriate doc string might be be something like "Overridden by depends build" to indicate that cached values have been overridden.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If writing the cache here really is necessary though...

It is. Otherwise, the user won't be able to override a build option via command line.
For example, passing -DMULTIPROCESS=OFF won't have any effect.

This is a specific of toolchain files.

... I'd think appropriate doc string might be be something like "Overridden by depends build" to indicate that cached values have been overridden.

Docstrings are available via -LH command-line option or in cmake-gui. And you are right that they shouldn't be empty.

However, its content must just be copy-pasted from the option() commands from the main CMakeLists.txt file. Otherwise, for example, when the user passes -DMULTIPROCESS=OFF, it ends with:

// Overridden by depends build
MULTIPROCESS:STRING=OFF

which is misleading.

Copy link
Owner Author

@hebasto hebasto Mar 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... you are right that they shouldn't be empty.

Fixed in #122.

# Distributed under the MIT software license, see the accompanying
# file COPYING or https://opensource.org/license/mit/.

function(target_capnp_sources target)
Copy link

@ryanofsky ryanofsky Mar 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function seems generally useful, so it would be great to move this module to https://github.com/chaincodelabs/libmultiprocess/tree/master/cmake /module, and use it upstream to replace hardcoded add_custom_command calls, and install it so it could be reused by the bitcoin build.

@hebasto hebasto marked this pull request as draft March 12, 2024 19:49
Copy link

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review ACK 3542d08

set(MULTIPROCESS ON CACHE STRING "")
endif()
if(NOT MPGEN_PREFIX)
set(MPGEN_PREFIX "${CMAKE_FIND_ROOT_PATH}/native" CACHE PATH "")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about "libmultiprocess codegen tool prefix"?

Well "libmultiprocess codegen tool prefix" already seems to be the documentation string for this option in cmake/optional.cmake so that seems very good.

But I'm confused about why any documentation string is required at all in depends/toolchain.cmake.in which should just be overriding values, not defining new options. If I understand https://cmake.org/cmake/help/latest/command/set.html correctly, in-memory values naturally override cached values, so it seems like the ideal thing would be to stop specifying CACHE <type> <docstring> arguments in this file, and just set the values in memory. If writing the cache here really is necessary though, I'd think appropriate doc string might be be something like "Overridden by depends build" to indicate that cached values have been overridden.

@hebasto
Copy link
Owner Author

hebasto commented Mar 18, 2024

Unfortunately, those target import files do not propagate dependency targets. As such, they have to be handled separately which increases complexity.

Hmm, what does this mean specifically? It seems like the installed cmake files are calling add_library and add_executable to add targets and setting the needed properties. Does something need to be improved in https://github.com/chaincodelabs/libmultiprocess/blob/master/CMakeLists.txt, because current install(EXPORT...) lines are not enough?

The targets from the CapnProto package are not imported. Resolved in chaincodelabs/libmultiprocess#96:

include(CMakeFindDependencyMacro)
find_dependency(CapnProto)

hebasto added a commit that referenced this pull request Mar 18, 2024
840e494 fixup! build: Generate `share/toolchain.cmake` in depends (Hennadii Stepanov)

Pull request description:

  See discussion in #118 (comment).

  Can be tested in the following ways:
  - applying the `-LH` command line option
  - using `cmake-gui`
  - direct observing of the `CMakeCache.txt` file content

ACKs for top commit:
  pablomartin4btc:
    tACK 840e494

Tree-SHA512: fd441457dc4df44b54c5fe98119786126db6b592f58ce7bca642a65921ffb9572d0e2afca07471666f425b647ef69f860228b8a0d61d02468d41edccad25627b
@hebasto hebasto marked this pull request as ready for review March 18, 2024 11:25
@hebasto
Copy link
Owner Author

hebasto commented Mar 18, 2024

Rebased due to the conflicts and undrafted.

Added lacking docstrings.

@hebasto
Copy link
Owner Author

hebasto commented Mar 26, 2024

Rebased.

ryanofsky added a commit to chaincodelabs/libmultiprocess that referenced this pull request Mar 29, 2024
66643d8 cmake, refactor: Use `target_capnp_sources` for examples (Hennadii Stepanov)
bd2dfe2 cmake, refactor: Use `target_capnp_sources` for `mptest` target (Hennadii Stepanov)
d9ec22f cmake: Add `LibmultiprocessMacros` module (Hennadii Stepanov)

Pull request description:

  This PR introduces the `LibmultiprocessMacros` module that is used internally and might be exported as a part of the (future) `LibmultiprocessGen` package (it is a subject of the follow-up [PR](#96)).

  Also see a discussion in hebasto/bitcoin#118.

ACKs for top commit:
  ryanofsky:
    Code review ACK 66643d8

Tree-SHA512: b97fcb2ce7b2085b3a041c422e3f51f06b8bf7a0abaa5baa7f39db2bf03491447bf7af073c95fb8bb6bc602d30e0c8856ae523954980cdb85afd87442c0b909a
@hebasto
Copy link
Owner Author

hebasto commented Mar 30, 2024

Reworked in a clean CMake's way using the recent updates in the https://github.com/chaincodelabs/libmultiprocess repository.

However, not using the last commit due to an issue with package search.

Add "Linux 64-bit, multiprocess" task.
@hebasto
Copy link
Owner Author

hebasto commented Apr 3, 2024

Rebased.

@hebasto
Copy link
Owner Author

hebasto commented Apr 3, 2024

@ryanofsky

While I'm still looking into the recent changes in the upstream repo, do you think it is reasonable to proceed with this PR as it is to unblock the following work on the CI stuff?

Anyway, we're likely to revisit this code, once the upstream packaging improvements conclude.

@ryanofsky
Copy link

While I'm still looking into the recent changes in the upstream repo, do you think it is reasonable to proceed with this PR as it is to unblock the following work on the CI stuff?

Of course, do you need anything from me?

@hebasto
Copy link
Owner Author

hebasto commented Apr 3, 2024

While I'm still looking into the recent changes in the upstream repo, do you think it is reasonable to proceed with this PR as it is to unblock the following work on the CI stuff?

Of course, do you need anything from me?

Approval?

:)

@ryanofsky
Copy link

Hmm, I'm not sure if you want me to literally ACK the PR since it is just going into a private branch. The thing I still don't understand is why the depends system is defining cache options like set(MULTIPROCESS ON CACHE STRING "") that don't have documentation or just duplicate options in the top level cmake file. I don't understand why same options would be defined two places, instead of just once or why we would want two copies of the same documentation in different files. I don't think this should block anything and you should definitely proceed with the work, but I just don't understand everything that is going on yet.

@hebasto
Copy link
Owner Author

hebasto commented Apr 3, 2024

The thing I still don't understand is why the depends system is defining cache options...

If depends set such options as non-cache variables, the user won't be able to override them in the command line, for example, with -DMULTIPROCESS=OFF.

... set(MULTIPROCESS ON CACHE STRING "") that don't have documentation...

That is no longer the case in general. But documentation is missed for MULTIPROCESS and I'm going to fix it shortly in this PR.

@hebasto
Copy link
Owner Author

hebasto commented Apr 3, 2024

I don't understand why same options would be defined two places, instead of just once or why we would want two copies of the same documentation in different files.

I don't have a better implementation for now.

@fanquake
Copy link

fanquake commented Apr 3, 2024

If depends set such options as non-cache variables, the user won't be able to override them in the command line, for example, with -DMULTIPROCESS=OFF.

So this is to accomodate someone who does a depends build, specifically enabling multiprocess, who then wants to use the toolchain file, but also disable multiprocess?

@ryanofsky
Copy link

I don't have a better implementation for now.

Understood, and I don't have one either. I think you should definitely proceed with you have and if there is anything I can do to help just let me know.

@hebasto
Copy link
Owner Author

hebasto commented Apr 3, 2024

If depends set such options as non-cache variables, the user won't be able to override them in the command line, for example, with -DMULTIPROCESS=OFF.

So this is to accomodate someone who does a depends build, specifically enabling multiprocess, who then wants to use the toolchain file, but also disable multiprocess?

Yes, it is.

@fanquake
Copy link

fanquake commented Apr 3, 2024

Shouldn't they just not enable multiprocess in the first place?

@hebasto
Copy link
Owner Author

hebasto commented Apr 3, 2024

Shouldn't they just not enable multiprocess in the first place?

Of course, they should not.

I'll take more time to think about it.

@hebasto
Copy link
Owner Author

hebasto commented Apr 8, 2024

I'm going to merge this PR as it is.

However, handling of the build configuration variables in the depends toolchain file should be revisited.

@hebasto hebasto merged commit c1e1967 into cmake-staging Apr 8, 2024
30 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants