-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix the gradle build configuration for the Android platform #66935
Fix the gradle build configuration for the Android platform #66935
Conversation
0a1b686
to
3178b04
Compare
supportedFlavors = ["editor", "template"] | ||
supportedFlavorsBuildTypes = [ | ||
// The editor can't be used with target=release as debugging tools are then not | ||
// included, and it would crash on errors instead of reporting them. | ||
"editor": ["dev", "debug"], | ||
"template": ["dev", "debug", "release"] | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know what gradle needs but I think it would be clearer if we followed the same structure as in scons, so:
supportedFlavors = ["editor", "template_debug", "template_release"]
supportedBuildTypes = ["regular", "dev"] // In SCons it's just a boolean, so could be the same here if that works.
dev_build=yes
can now be used with any target so target=template_release dev_build=yes
is also a valid use case (gives template_release.dev
lib). It's not a particularly useful combination but it's IMO better if gradle follows the same logic of having only three targets and then a bool for dev_build
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new build model unfortunately doesn't match with Gradle's build layout.
Gradle has the concept of build types and product flavors:
- A product flavor is a different version of the project (e.g: demo version vs full version). This aligned somewhat better with the previous build architecture where
tools=no
corresponded to thetemplate
flavor andtools=yes
corresponded to theeditor
flavor - A build type on the other hand mapped to our previous concept of target and is used configure the build configuration (debug symbols, optimization, etc)
With the new build model, we still have two product flavors ('editor' and 'template') and still three build types ('dev', 'release_debug' and 'release'), so the gradle build model is still valid, we just need to update the mapping when we generate the scons command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The build types are also shared across the project modules, while the flavors are linked:
- The
app
module maps to thetemplate
flavor - The
editor
module maps to theeditor
flavor - As a dependency, the
lib
module is configured to automatically update its flavor and build type to match.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds great, thanks for the explanation :)
Refactor needed following #66242