oyvindberg/bleep

Parameterize source generators

Opened this issue · 3 comments

nafg commented

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

    sourcegen:
      main: bookphone.scripts.SlickCodegen
      project: scripts

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.

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

nafg commented

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.

nafg commented

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