oyvindberg / bleep

A bleeping fast scala build tool!
MIT License
150 stars 23 forks source link

Parameterize source generators #399

Open nafg opened 3 months ago

nafg commented 3 months ago

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.

oyvindberg commented 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

nafg commented 2 months ago

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 2 months ago

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