Have an option to propagate CMAKE_PREFIX_PATH

[attilaolah]

I see that in the libgit2 example, we pass along CMAKE_PREFIX_PATH manually. This is nice for one or two packages, but can be an annoyance when there is a large tree of dependencies.

It would be awesome if the cmake() rule could preserve its output (the copy_:rule_name/:rule_name directory) in the provider it returns, and then (optionally) pass them on to the dependent cmake() builds.

Adding the info to the provider seems simple enough, but we might want to control how or which dependencies are added to the cache entries. We could introduce an optional prefix_path command, with the following logic:

• If None (the default), then copy from all transitive cmake dependencies.
• If provided, it must be a list of labels that are (a) a direct or transitive dependency, and (b) also cmake() rules, or at least rules that provide the same provider that holds the prefix path info.

Then aggregate all the prefix path variables, ;-join them and optionally append to an existing CMAKE_PREFIX_PATH from the cache_entries, or else generate a new entry.

This should make it so that by default CMake dependencies can find each other by default.

[attilaolah]

I think this could be done in a similar way we handle PKG_CONFIG_PATH.

[jsharpe]

My thoughts on how to implement this were to add a new provider for providing a CMAKE_PREFIX_PATH entry or PKG_CONFIG_PATH entries because its not necessarily just cmake projects that would generate cmake config files (c.f. boost) and likewise cmake can consume or create pkg-config files too. This would also pave a path to a repository rule to make system installed pkg-config or cmake based dependencies available to rules_foreign_cc targets.

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_foreign_cc!

[github-actions]

This issue was automatically closed because it went 30 days without a reply since it was labeled "Can Close?"

[matt-sm]

but can be an annoyance when there is a large tree of dependencies

+1

Just trying to picture how the provider would work.

We could start with cmake rules. The end result I assume is CMAKE_PREFIX_PATHs equivalent of ${EXT_BUILD_DEPS}/<package>, for the package and each transitive dep, similar to the libgit2 example.

The paths could be read and passed to _merge_prefix_paths where they'd be merged with user-defined paths.

The dep cmake rule could output the new provider (or perhaps update ForeignCcDepsInfo?) and automatically add the CMAKE_PREFIX_PATHs.

@jsharpe perhaps we could re-open this issue.