Demonstrate per-variant source layout

[lacasseio]

Everything in the other sample still applies, here we will add a source to a specific variant:

class GenerateVariantCompilingWarning extends DefaultTask {
    @Input
    abstract Property<String> getVariantName()

    @OutputFile
    abstract RegularFileProperty getOutputFile()

    @Inject
    GenerateVariantCompilingWarning(ProjectLayout layout) {
        outputFile.convention(layout.buildDirectory.file("tmp/${name}/warning.c"))
    }

    @TaskAction
    private void doGenerate() {
        outputFile.get().asFile.text = """
#pragma message "Compiling for variant : ${variantName.get()}"
"""
    }
}

application {
    variants.configureEach { variant ->
        variant.cSources.from(project.tasks.register("generate${variant.name.capitalize()}", GenerateVariantCompilingWarning) { variantName = variant.name })
    }
}

Note usage of project.tasks, TasksAwareComponent has getTasks() method. In our case, we want to register a task on the project hence access to project.getTasks().

Also, note that we use the variant name in the task name as each variant will create a task that we need to distinguish or else a configuration failure will happen because of duplicated task (tasks with the same name).

Finally, note that we use from (see setFrom vs from) because we append the generated sources to the conventional. If we were to setFrom, we would discard the general sources configured on the component and be left with only the generated source file.

[pedrolamarao]

Thank you! This seems to enable per-target sources, which is going to be incredibly helpful!

[lacasseio]

It's not yet working but should soon be worked on. It's a matter of using the mixin for HasCSources, HasCppSources, etc. dynamically on variants as well. The major change that is coming soon-ish is for LanguageSourceSet to be the domain object representing the source to object files transformation, including incoming dependencies, compile tasks and, later, source compatibilities, etc. The HasCSources and co. should just be dumb properties for users to configure to represent the intent.