https://pantsbuild.org/ logo
Join Slack
Powered by
<@UB2J9BQA0>: oh! … i understand now what you mean...
# development
w
@hundreds-father-404: oh! … i understand now what you mean by a module mapping for codegen targets. that’s basically akin to treating them as thirdparty
for the JVM, that would basically mean not doing symbol-level, and instead doing package level, the way we do for thirdparty code. cc @ancient-vegetable-10556
so yea, that might be reasonable, since it would avoid codegening anything while dependency inference ran
h
I don't know how JVM codegen is used well enough to comment if package-level is sufficient, but that makes sense to me
since it would avoid codegen anything while dependency inference ran
A very desirable objective. A big goal of Pants v2's codegen redesign is for codegen to be as lazy as possible -- Fyi this is what Python codegen module mapping looks like when considering multiple resolves (necessary for JVM too) https://github.com/pantsbuild/pants/blob/6635d57d5c927d5ba61bf9ef84669e555e9bcddf/src/python/pants/backend/codegen/protobuf/python/python_protobuf_module_mapper.py#L36-L67
To repeat what I said in the meeting: it is necessary (w/ Python at least) for each codegen plugin to fill in its own module mapping logic; that can't be generalized. That's because they each have their own unique semantics of what packages they generate, e.g. Thrift with the 
namespace py
option
w
yep
Open in Slack
PreviousNext
Powered by