Status Update
Comments
ma...@gmail.com <ma...@gmail.com> #2
+1 for addGeneratedSourceDirectory(Provider<Directory>)
. For simplicity and also for consistency with non-android Kotlin and Java projects.
For an example, we have tutorials that explain how code generation work and tell users to open generated files to understand what's going on under the hood (See
If sources outside of build/
is the issue, I'd be OK with a runtime check that fails if Provider<Directory>
does not resolve to a child of layout.buildDirectory
.
je...@google.com <je...@google.com>
je...@google.com <je...@google.com> #3
I am not in favor of adding a new API with Provider<> which is problematic because some folks will set it to a value which is not mapped from a TaskProvider<> which mean the task dependency will not be carried with it.
Instead, I propose that AGP use the Propery.setConvention()
to set its preferred location but users can override the value by using the Property.set
method.
something like :
val addSourceTaskProvider = project.tasks.register<AddCustomSources>("addCustomSources") {
outputFolder.set(File(project.layout.buildDirectory.asFile.get(), "toml/gen"))
}
would now respect the toml/gen
location.
je...@google.com <je...@google.com> #4
done. now using set() to set the location of the output folder will be respected.
Change-Id: I8a8ebb250b8e3ee4ee3b1a5f4b00ce91bd3f80d4
an...@google.com <an...@google.com> #5
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Ladybug Feature Drop | 2024.2.2 Canary 1
- Android Gradle Plugin 8.8.0-alpha01
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
je...@google.com <je...@google.com> #6
after more conversations, we decided that we might want to go to a different direction to continue providing a good IDE experience. I will rollback the change mentioned above until we can design something that fits the requirements.
Description
SourceDirectories.addGeneratedSourceDirectory
works the same way as the artifact API and takes over the output for the tasks. For example in thetoml/gen
), running the verification task shows that the location is changed tobuild/generated/toml/debugAddCustomSources
.It does in fact work if you pass this to multiple variants. For instance changing the recipe to something like this:
will in fact works. However the look of the API make it looks like it would not work.
Part of this is the way some of our other APIs work (for example transforms on Artifact are very variant specific).
At the very least we should document that it can in fact be used for multiple variantss. We should also consider making it more obvious (maybe the API just needs to receive a
Provider<Directory>
, though I think there are potentially issue as the location should be inbuild/
?)