would it be possible to generate accessors/extensions in a dynamic way? I'd like to use the power of Gradle for something else than a vanilla coding project, I'd like it to use it to configure some setup hassle (like this one), where I'll read some file, parse its properties and then provide them as statically typed for the user

You can write your own gradle plugin, create an project extension extending a DomainCollection and add elements to it.

let me give you a more concrete example

val inpTensor = Tensor.build("input_1", "bxyc", img1);
val outputBlankTensor = Tensor.buildBlankTensor("conv2d_19",
                "bxyc", longArrayOf(1, 512, 512, 3), FloatType());

I'd like to generate on the fly, based on some parsing previously done, options like

input_1

,

bxvc

and a

dimensions: LongArray

Do you really want to configure your model in your build script? I have an similar case (webservice but anyway) and I use different sub projects one called infrastructure that contains the webservice definition in the normal Kotlin code (src/main/kotlin) which is executed during configuration and generates output for another sub project. Main reason for this way is to not invalide my build logic when making ABI compatible changes.

no, it's all pure speculation atm

AFAIK there is no way to use the underlying code gen from Gradle directly so if you want to use the extension version you also need to use Gradles API like NamedDomainProvider

ah wait, I think I got what you mean, the webservice definition project will output something that will be used as input by another project?

Yes, exactly

that's a nice idea

Well, you can model your Model using a project extension but the type of each registered/generated accessor will be a Provider, like the generated tasks/sourceSets providers. So you need to handle that API too (or always call get).

the new assign operator could play nice there

It depends, do you want to reuse an existing Tensor build library or do you want to write your own? Because the assign operator still requires Gradles api (and runtime). Personally, I like reusing existing/write an independent library more than using Gradles Api if it can be avoided.

No, I'd simply like to use a kotlin/gradle project as a powerful configuration helper, exploiting the Gradle task cache and hierarchy and the kotlin DSL power