Open nafg opened 3 months ago
This should already be supported.
When bleep calls a sourcegen script, it calls it with the names of all (cross-)projects it should generate code for. the project names are passed as arguments, something like this java classfile -- -p project1 -p project2
if you use BleepCodegenScript
, you get this information easily available in targets
object GeneratedRowParsers extends bleep.BleepCodegenScript("GeneratedRowParsers") {
override def run(started: Started, commands: Commands, targets: List[GeneratedRowParsers.Target], args: List[String]): Unit = {
targets.foreach(target => println(s"name: ${target.project}, generatedSourcePath: ${target.sources}, generatedResourcesPath: ${target.resources}"))
}
Inside there you are free to dispatch on the project name and do different things.
Since scripts are code, you're also free to create one object
for each project and share code like normal
That's not the same thing. For instance, it should be possible for the code generator to just be a library. But the information that distinguishes the how each module uses it is just data, that belongs local to the module('s config), not hardcoded in some central pattern match in scripts
.
I suppose one way to "parameterize from the call site" is to use the subproject's local filesystem, for instance a config file or expecting files in a certain location
My use case: I have a BleepCodegenScript based on https://github.com/nafg/slick-additions?tab=readme-ov-file#slick-additions-codegen. But I want to generate different things in different modules. So I have in my bleep.yaml
Ideally I should be able to include the same snippet in different modules but somehow provide different arguments to pass to them.
Other approaches are branching in the code generator based on the project, or using inheritance (or composition) to provide separate code generator entry point classes while still sharing most of the code.