[TIMOB-12025] CLI: Support build configurations to allow multiple build outputs
| GitHub Issue | n/a |
|---|---|
| Type | New Feature |
| Priority | High |
| Status | Open |
| Resolution | Unresolved |
| Affected Version/s | Release 3.0.0 |
| Fix Version/s | n/a |
| Components | CLI |
| Labels | cb-tooling, notable, qe-cli100112, qe-nfc, titaniumlib |
| Reporter | Dustin Hyde |
| Assignee | Chris Barber |
| Created | 2012-12-11T20:34:07.000+0000 |
| Updated | 2020-03-06T21:36:22.000+0000 |
Description
CLI: Allow Multiple Build Outputs, this would later be integrated into the Titanium Studio UI.
Here is a user story:
Would be *really* nice if we could build into build configs different rules before the app is built.
E.g working for a client with different apps for language variants. So they don't want one app multi-language but separate fixed language builds.
Could be easily achievable if I had the ability to say:-
For GB config use this info.plist, this XML file, this assets folder (videos, audios and images that's are English)
For the same project I do a DE build script that uses other folders.
Result is one codebase, two separate build outputs and it remains nicely compatible with Git
Even an "ignore these files/folders" would help
<build-configurations>
<configuration name="development">
<deploy-type>development</deploy-type>
<encode-i18n>false</encode-i18n>
<minify-js>false</minify-js>
<minify-css>false</minify-css>
<encrypt-js>false</encrypt-js>
<optimize-ios-pngs>false</optimize-ios-pngs>
<remove-unused-ti-apis>false</remove-unused-ti-apis>
<allow-debugging>true</allow-debugging>
<allow-profiling>true</allow-profiling>
<show-errors>true</show-errors>
</configuration>
<configuration name="test">
<deploy-type>test</deploy-type>
<encode-i18n>true</encode-i18n>
<minify-js>true</minify-js>
<minify-css>true</minify-css>
<encrypt-js>false</encrypt-js>
<optimize-ios-pngs>true</optimize-ios-pngs>
<remove-unused-ti-apis>true</remove-unused-ti-apis>
<allow-debugging>true</allow-debugging>
<allow-profiling>true</allow-profiling>
<show-errors>true</show-errors>
</configuration>
<configuration name="production">
<deploy-type>production</deploy-type>
<encode-i18n>true</encode-i18n>
<minify-js>true</minify-js>
<minify-css>true</minify-css>
<encrypt-js>false</encrypt-js>
<optimize-ios-pngs>true</optimize-ios-pngs>
<remove-unused-ti-apis>true</remove-unused-ti-apis>
<allow-debugging>false</allow-debugging>
<allow-profiling>false</allow-profiling>
<show-errors>false</show-errors>
</configuration>
</build-configurations>
Another use for this, other than internationalization, would be where a base app is "branded" for multiple clients. The code base is the same (or close to the same), but the assets are unique for each client. I think this is a great idea for productivity. Not limited to internationalization.
Absolutely - my original thought was not just for internationalisation - your example is precisely what sort this would allow. e.g. Full / lite versions etc. Also some sort of inheritance based build config would be cool e.g. to allow for Lite / Full versions.
bump ^^
Still looking for this feature. I really could have used an "ignore these files/folders" in the app I'm working on now.
@Shawn, there is no spec for this and there is no time to develop it for 3.2, hence it's been re-prioritized as low priority.
bump
+1