This is an archive of the discontinued LLVM Phabricator instance.

[CMake] Fix FindGRPC cmake module to allow different layering
ClosedPublic

Authored by steven_wu on Oct 11 2022, 1:50 PM.

Details

Summary

Take the library target out of generate_protos function so the caller
can decide where to layer the library using the source generated from
the function.

Fixes: https://github.com/llvm/llvm-project/issues/58075

Diff Detail

Event Timeline

steven_wu created this revision.Oct 11 2022, 1:50 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 11 2022, 1:50 PM
steven_wu requested review of this revision.Oct 11 2022, 1:50 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptOct 11 2022, 1:50 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Hmm, as mentioned on the bug, I think wrapping the deps and generated sources into a library is an important part of what the build rule does.

If we need to split it up like this, I think a generate_clang_protos wrapper in FindGRPC.cmake might be the right place to encapsulate it.

Address review feedback

Herald added a project: Restricted Project. · View Herald TranscriptOct 12 2022, 11:44 AM
Herald added a subscriber: bmahjour. · View Herald Transcript

Was missing the latest feedback. Bump FindGRPC module to top layer.

sammccall accepted this revision.Oct 12 2022, 12:26 PM

thanks!

cmake/Modules/FindGRPC.cmake
111

changing from function to macro means all the local variables here are done in the parent scope, which is hard to reason about.

I think the only reason you're doing that here is to return the filename in the ProtoSource variable, in which case set(${GeneratedSource} ${GeneratedProtoSource} PARENT_SCOPE) should do the job from a function.

111

nit: the plural is in the wrong place: rather generate_proto_sources?
this generates the multiple sources for a single proto, rather than the other way around.

(I'm not sure why the original was plural, but this makes it somehow more confusing)

This revision is now accepted and ready to land.Oct 12 2022, 12:26 PM
steven_wu added inline comments.Oct 12 2022, 12:40 PM
cmake/Modules/FindGRPC.cmake
111

The reason why it is a macro is I don't know any elegant way to pass all the DEPEND down to add_*_library.

steven_wu updated this revision to Diff 467243.Oct 12 2022, 1:01 PM

Minor rename

sammccall added inline comments.Oct 12 2022, 1:05 PM
cmake/Modules/FindGRPC.cmake
111

The reason why it is a macro is I don't know any elegant way to pass all the DEPEND down to add_*_library.

... oh, yikes, we're passing through by pretending they're ${ProtoFile}, I didn't see that :-\

I guess the easiest option is just to change that name to something like ProtoArgs in the wrapping function, and add a bit of documentation.
I think using CMAKE_PARSE_ARGUMENTS in the wrapping function is an option though, and then pass the unparsed arguments through?

steven_wu added inline comments.Oct 12 2022, 1:23 PM
cmake/Modules/FindGRPC.cmake
111

Ah, I just learnt the unparsed_argument option. Then it is not too bad. Fixing.

steven_wu updated this revision to Diff 467247.Oct 12 2022, 1:24 PM

Turn generate_proto_sources back to function and forward argument more elegantly.

sammccall accepted this revision.Oct 12 2022, 1:38 PM

Thanks, LG!

This revision was landed with ongoing or failed builds.Oct 12 2022, 3:35 PM
This revision was automatically updated to reflect the committed changes.