Comments (17)
Well since 1.3.60, ios
dsl actually creates both iosArm64 and iosX64 targets and common sourcesets for these two.
https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#target-shortcuts
I need to check the behavior
from buildkonfig.
I've quickly tested ios
dsl in 1.3.61 and it seems to indeed create a common sourceset for both iosArm64
and iosX64
.
When I run generatBuildKonfig
task it creates BuildKonfig for iosArm64
and iosX64
and seems to compile fine for both targets.
from buildkonfig.
Closing this issue as it's solved in 1.3.60+
from buildkonfig.
What I am doing now in my current project is changing iOS target depending on a value passed from Xcode(or command line).
When I build iOS framework, I pass a property like this
./gradlew copyFramework -Pkotlin.target=iosArm64
provided kotlin.target
decides which target Gradle should configure, thus we don't need to manage two sourceSets.
kotlin {
def iosTargetName = project.findProperty("kotlin.target") ?: "iosX64"
def iosTarget = presets.getByName(iosTargetName)
android()
targetFromPreset(iosTarget, "ios") {
binaries {
framework([DEBUG, RELEASE])
}
}
sourceSets {
androidMain {}
iosMain {}
}
}
from buildkonfig.
I use the switching mechanism as well. I'm also trying out 1.3.60 but I'm having problems with other libraries.
from buildkonfig.
I also have this issue, however it is not easy to solve with a switch flag, because I'm building, and need to build all iOS targets for a static library to include in a fatLibrary.
Is there anything I can do to solve this issue myself? Or could this be fixed by adding a flag, to only generate the key value for common?
from buildkonfig.
@glootjofo do you have any specific implementation for each iOS target?
If there's no target-specific code, the code in the comment above is the only way for now.
./gradlew linkReleaseIosFramework -Pkotlin.target=iosX64
./gradlew linkReleaseIosFramework -Pkotlin.target=iosArm64
./gradlew linkReleaseIosFramework -Pkotlin.target=iosArm32
could this be fixed by adding a flag, to only generate the key value for common?
Yes, probably we need this feature.
from buildkonfig.
Sadly there is target-specific code. In my case, having only the generated key-value in common would solve my specific case. Because I only need git information that is shared across all targets.
Is it something that could be added with ease?
from buildkonfig.
@kuuuurt Does adding an option to generate a common BuildKonfig object(no expect-actual) solve your problem?
I'm leaning towards adding generateCommonObject
flag(looking for better flag name).
Is it something that could be added with ease?
It depends on how we implement, but shouldn't be that difficult
from buildkonfig.
I came up with two idea
- User need to explicitly specify that only common object is needed(and ignore/warn if
targetConfigs
is specified)
or
- The plugin will generate a common object if no
targetConfigs
is specified
Though I prefer the first one
from buildkonfig.
First one works for me. For now I have created a task that does this without BuildKonfig, but obviously i'll swap back if you get this feature in.
tasks.create("createCommonBuildConfig") {
group = "gloot"
val BuildConfigBody = """internal object BuildConfig {
val SDK_VERSION: String = "${getGitTagFromCurrentBranch(project)}"
}"""
val packageName = randomPackageName
val buildConfigDirectory = File(buildDir, "buildconfig")
buildConfigDirectory.deleteRecursively()
buildConfigDirectory.mkdir()
val commonMain = File(buildConfigDirectory, "commonMain")
commonMain.mkdir()
var previousCreatedFolder = commonMain
packageName.split(".").forEach {
val createdFolder = File(previousCreatedFolder, it)
createdFolder.mkdir()
previousCreatedFolder = createdFolder
}
val buildConfigSourceFile = File(previousCreatedFolder, "BuildConfig.kt")
buildConfigSourceFile.createNewFile()
buildConfigSourceFile.writeText(BuildConfigBody, Charsets.UTF_8)
val mppExtension = project.extensions.getByType(KotlinMultiplatformExtension::class.java)
mppExtension.sourceSets.getByName("commonMain")
.kotlin.srcDir(commonMain.toRelativeString(project.projectDir))
}
from buildkonfig.
Sorry for being away for a while.
The first idea would be nice! Though I think a warning isn't needed. I think of it as just overriding the value or maybe adding more platform-specific values.
I'm just thinking about what if these common BuildKonfigs are just used among a subset of the targets. For example:
Common
- Target 1
- Target 2
- Target 3
- Target 4
IosCommon
- Target 3
- Target 4
I can have a:
defaultConfigs {
// For Target 1, 2, 3, and 4
}
But I'd have to write the common configs for iOS individually:
targetConfigs("target3") {
...
}
targetConfigs("target4") {
...
}
What do you think about a:
defaultConfigs {
...
subDefaultConfigs(listOf("myTarget3", "myTarget4")) {
...
}
}
targetConfigs("target3") {
// Only Target 3 specific
}
targetConfigs("target4") {
// Only Target 4 specific
}
from buildkonfig.
Ok, first let me clarify your example as target
in your example has two meanings.
targetConfigs
API is for setting target-specific values. In this context, target
means platform, such as Android and iOS.
targetConfigs
(and defaultConfigs
) optionally takes a string value, which I call flavor
in BuildKonfig.(in respect for Android)
flavor is here to switch values depending on your environment, such as development
and production
(or something like paid
and free
).
So in your example you wrote
Common
- Target 1
- Target 2
- Target 3
- Target 4
IosCommon
- Target 3
- Target 4
but this is actually
Common
- Flavor 1
- Flavor 2
- Flavor 3
- Flavor 4
IosCommon
- Flavor 3
- Flavor 4
right?
So based on above, what you need is the ability to de-duplicate values that are common in a subset of your flavors. Am I right?
from buildkonfig.
I confirmed that the configuration below is valid
// set values common in some of the targets
targetConfigs {
["ios", "android"].each { key ->
create(key) {
buildConfigField "STRING", "test", "test string"
}
}
}
// set values common in "dev" and "stg" flavor
["dev", "stg"].each { flavor ->
targetConfigs(flavor) {
ios {
buildConfigField "STRING", "commonkey", "commonvalue"
}
}
}
// you can set additional value for one of the flavors
// multiple calls to same target config will result in merged BuildKonfig
targetConfigs("dev") {
ios {
buildConfigField "STRING", "iosdevkey", "iosdevvalue"
}
}
from buildkonfig.
Oh. In that case, that's good then!
Now, it's just the merging thing.
Have you verified the behavior on 1.3.60? If it works, then we might just have to upgrade to it.
from buildkonfig.
I've changed my mind and went this way
- The plugin will generate a common object if no
targetConfigs
is specified
Let me know what you think. I'm gonna merge this next Tuesday or Wednesday.
from buildkonfig.
In that case, I guess this one's solved in 1.3.61!
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
- BuildType & ProductFlavor & sourceSets support ? HOT 1
- Plugin generates invalid class so build fails HOT 5
- Readme does not document hierarchical project support HOT 2
- Type ...BuildConfig is defined multiple times HOT 2
- BuildKonfig doesn't work with npm-publish HOT 4
- Set generated value visibility modifier public/internal HOT 2
- non-flavored defaultConfigs must be provided. HOT 3
- Unresolved reference HOT 2
- Rename `buildkonfig` to `buildKonfig` HOT 1
- Support for Kotlin 1.9.0? 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.