Comments (9)
You may have misunderstood the current API a bit(or just a typo?).
Here's a minimal configuration block for a simple BuildKonfig(current API)
buildkonfig {
packageName = "com.example.app"
// default config is required
defaultConfigs {
buildConfigField(STRING, "name", "value")
}
}
If you want to add some flavored config, you can add those by defining targetConfigs
.
buildkonfig {
packageName = "com.example.app"
// default config is required
defaultConfigs {
buildConfigField(STRING, "name", "value")
}
targetConfigs {
// names in create should be the same as target names you specified
create("android") {
buildConfigField(STRING, "name2", "value2")
buildConfigField(STRING, "nullableField", "NonNull-value", nullable = true)
}
create("ios") {
buildConfigField(STRING, "name", "valueForNative")
}
}
}
So, you can't nest defaultConfigs
, and can't define flavor
next to packageName
or objectName
like you wrote.
Here's my proposal, inspired by yours. What do you think?
buildkonfig {
// keep the current API for backward compatibility, if possible
packageName = "com.example.app"
defaultConfigs {
// ...
}
// below is the new API
// register method should receive the *required* name parameter so that we can make sure that everyone names their configs.
register(name = "AppConfig") {
packageName = "com.example.app"
// As the name is a required parameter, we can simply provide an option for visibility
// see the previous discussion: https://github.com/yshrsmz/BuildKonfig/issues/31
visibility = INTERNAL/PUBLIC
defaultConfigs {
buildConfigField(STRING, "name", "value")
}
// I still think it's good idea to pass flavor as a parameter for defaultConfigs/targetConfigs
defaultConfigs(flavor = "dev") {
// flavored defaultConfigs
}
targetConfigs {
// default targetConfigs
}
targetConfigs(flavor = "dev") {
// flavored targetConfigs
}
}
register(name = "ApiConfig") {
packageName = "com.example.app"
}
}
from buildkonfig.
@yshrsmz As you said, it would be good to keep the existing APIs alive for compatibility. Also your new proposal is so reasonable to implement. Thanks for the great suggestion!
from buildkonfig.
Can I take on this task?
from buildkonfig.
@l2hyunwoo
Sure, but we first need to design & agree on the new API.
Do you have anything in mind?
I think SQLDelight is a good source of ideas.
https://cashapp.github.io/sqldelight/2.0.0/android_sqlite/
from buildkonfig.
@yshrsmz Oh thanks to provide good reference :)
I skimmed the gradle plugin reference, and it is easy to use I think.
It'll be nice that configuration api should be based on above one. And it'll be better with integrating(or renaming) some properties in this task.
configure<BuildKonfigExtension> {
packageName = "${ProjectSettings.PROJECT_ID}.common"
name = "ApiBuildKonfig"
flavor = "dev(stage, release etc)"
visibility = INTERNAL/PUBLIC
defaultConfigs {
buildConfigField(STRING, "BASE_URL", "www.asd.com", const = true)
}
}
from buildkonfig.
Assuming from your snippet you want to define a buildkonfig extension block for each BuildKonfig object, right?
configure<BuildKonfigExtension> {
name = "ApiBuildKonfig"
// ...
}
configure<BuildKonfigExtension> {
name = "SecretBuildKonfig"
// ...
}
I'm unsure if we can ensure that BuildKonfig object names are distinct with this setup.
from buildkonfig.
Assuming from your snippet you want to define a buildkonfig extension block for each BuildKonfig object, right?
right!
I'm unsure if we can ensure that BuildKonfig object names are distinct with this setup.
I understood what you worried about. When I was writing above design, I lost that design can't distinct objects brcause of configuration block is separated.
It'll be resolved with below structure.
defaultConfigs {
register {
packageName = "${ProjectSettings.PROJECT_ID}.common"
name = "ApiBuildKonfig"
flavor = "dev(stage, release etc)"
visibility = INTERNAL/PUBLIC
defaultConfigs {
buildConfigField(STRING, "BASE_URL", "www.asd.com")
}
}
register {
packageName = "${ProjectSettings.PROJECT_ID}.core"
name = "CommonKonfig"
flavor = "dev(stage, release etc)"
visibility = INTERNAL/PUBLIC
defaultConfigs {
buildConfigField(STRING, "BASE_URL", "www.asdd.com")
}
}
}
With above structure, configuration block will transform to NamedDomainObjectContainer
, so it can distinct object with name.
Reference - SQLDelightPlugin
from buildkonfig.
@yshrsmz If there's no doubt, I'll start this task, is it okay?
from buildkonfig.
@l2hyunwoo sure, let's do this 💪
from buildkonfig.
Related Issues (20)
- Cause: non-flavored defaultConfigs must be provided. HOT 2
- Specify flavor in build time HOT 7
- ios configuration and environment variables
- Support Kotlin 1.9.20 HOT 7
- Automate changelog generation
- BuildKonfigs objects are not available in dependent modules. HOT 1
- add an easy way to load flavor from arbitrary properties file HOT 2
- Add Support to change build types or Build Variants from dropdown like native android HOT 3
- target ios does not contains correct values. (ComposeApp module hierarchy) HOT 6
- How to configure for compose multiplatform nativeMain?
- Unable to detect shared ios SourceSet created by KMP plugin HOT 1
- Add option to disable @JsExport HOT 4
- [Kotlin v2] CONST_VAL_WITHOUT_INITIALIZER warnings HOT 1
- Support Kotlin 2.0.0
- Flavor Selection Based on Build Variants in Android HOT 4
- How to solve "Unresolved reference: BuildKonfig" error? HOT 4
- Support Gradle Config Cache HOT 3
- Issue With New Compiler Options DSL HOT 4
- Dependency Dashboard
- SourceSet change support HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from buildkonfig.