Tuist: unify project settings #5393
Conversation
…pp` or `.framework` throughout the projects in the repo
| configurations: .xcconfigFileConfigurations, | ||
| defaultSettings: .recommended | ||
| ), | ||
| settings: .framework, |
There was a problem hiding this comment.
I think the RevenueCat project does not need the code signing or the xcconfig files. Is that correct or am I missing something?
There was a problem hiding this comment.
Technically the frameworks do not, BUT this project has a host app inside that might need it if someone wants to run it manually.
I see two options:
- Set specific settings for the target
- Create a new project only for that
I think I prefer 1 for now, and if we experience any downsides, we can always split it
There was a problem hiding this comment.
I 100% agree. Thanks for the input! 🙌
There was a problem hiding this comment.
I just tried out the two apps inside the project: UnitTestsHostApp and BackendIntegrationTestsHostApp. These are actually empty apps only used to run tests on CI.
- Not having the xcconfig files is OK, since they don't really use any of the configs in them
- Not having the signing team doesn't seem a problem as these 2 apps can be totally run locally and I don't see the need of them run in actual devices (and it runs properly on Mac without signing anyway)
So I'd say we leave them like this for now. WDYT?
| configurations: .xcconfigFileConfigurations, | ||
| defaultSettings: .recommended | ||
| ), | ||
| settings: .framework, |
There was a problem hiding this comment.
Same as for RevenueCat
| /// This provides a standardized settings configuration that includes: | ||
| /// - Base settings from `.projectBase` | ||
| /// - Debug configuration with incremental compilation | ||
| /// - Release configuration with whole module optimization | ||
| /// - Recommended default settings | ||
| public static var project: Settings { | ||
| public static var app: Settings { |
There was a problem hiding this comment.
Lmk what you think of the name. I was also doubting with appProject.
There was a problem hiding this comment.
I think appProject is better, because the other one is called target which is pretty generic.
We cn also rename the other one to framework maybe?
There was a problem hiding this comment.
Not exactly. We now have .app, .target and .framework already. .framework is used for packages/libraries and .target is used by the apps target. Perhaps we should have
.appProject, .appTarget and .framework. WDYT?
📸 Snapshot Test4 modified, 701 unchanged
🛸 Powered by Emerge Tools |
298714e to
f802dcf
Compare
This PR makes it so that every tuist project in the repository uses one of the
Settingsdeclared in the constants (Tuist/ProjectDescriptionHelpers/Settings.swift)