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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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.
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? (I'm not sure why the original was plural, but this makes it somehow more confusing) |
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. |
cmake/Modules/FindGRPC.cmake | ||
---|---|---|
111 |
... 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. |
cmake/Modules/FindGRPC.cmake | ||
---|---|---|
111 | Ah, I just learnt the unparsed_argument option. Then it is not too bad. Fixing. |
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.