[TIMOB-12368] CLI: There's no way to set the build SDK from the new CLI
GitHub Issue | n/a |
Type | Bug |
Priority | Low |
Status | Open |
Resolution | Unresolved |
Affected Version/s | Release 3.0.0 |
Fix Version/s | n/a |
Components | CLI |
Labels | cb-tooling, ft |
Reporter | Tony Lukasavage |
Assignee | Chris Barber |
Created | 2013-01-22T03:08:13.000+0000 |
Updated | 2016-08-26T20:55:58.000+0000 |
Description
problem
The new CLI has an option for specifying a Titanium SDK, but this option doesn't actually use this SDK to build, only to bootstrap. No matter what value you use for --sdk, or any other option, it will only use the SDK set in the project's tiapp.xml. This makes testing multiple versions cumbersome and automation near impossible.
proposed solution
The --sdk option should actually use the specified SDK to build the project.
Comments
JSON Source
Is it possible to instead just make this generic and provide an option to override any tiapp.xml value? Or is this value common enough that we'd want a special shortcut for this?
I can't think of a practical app developer situation in which I'd want to specify a different CLI SDK vs a tiapp.xml SDK. It seems most logical to have
--sdk
change both, and to provide a new option(s) to configure the individual CLI or tiapp.xml SDKs in the rare cases you'd actually want them to be different.As a workaround: What I found while investigating the linked ticket is that if you remove the
ti sdk select
or the version you specify with the--sdk
arg. In either case, whatever is set withti sdk select
is used by the CLI to bootstrap.The problem here is the tiapp.xml parsing is done in the SDK, not the CLI. We designed it so that the SDK would always know how to parse the tiapp.xml. That way if TiSDK 3.4.0 added some new tiapp.xml tags, it could properly interpret them and it wouldn't matter if your Titanium CLI was up-to-date. As it turns out, nearly everybody has the latest Titanium CLI and the Titanium CLI is almost always shipped at the same time Titanium SDK. To properly solve this, we should create proxy commands for "build", "clean", "create", and "project" in the Titanium CLI and have the "build" proxy command do the tiapp.xml parsing. This is not trivial, but also isn't hard. If we're going to make this change, we may want to sit down and think things through and consider any other design changes such as the possible introduction of a daemon.
Not nearly so involved, I just submitted https://github.com/appcelerator/titanium_mobile/pull/5987 Functional review:
1. Create an app with the code above 2. Set the sdk-version in tiapp.xml to some arbitrary version 2. Run from the CLI with
ti build -p android --sdk 3.4.0
(other platforms should work, too). Log messages during the build will indicate that 3.4.0 was used to build, as should the label once the app launches.I commented on the pull request, but the proposed solution will not work. It ALWAYS overrides the tiapp.xml's
<sdk-version>
with the selected SDK. The whole point of the<sdk-version>
in the tiapp.xml is so that you can have certain apps designed to work with a specific version of the Titanium SDK. If you build an app that is designed for Titanium SDK 3.2.0, then it should not be using 3.3.0 or 3.1.0 or any version other than 3.2.0. This ticket should be closed as "Won't Fix", but it may be acceptable to add a\-\-force\-sdk <ver>
, but I'm not sold that this is a good idea.You can close that PR. I didn't think that it would be the best or correct solution, just a hack that works in some cases. Please don't close this ticket. The linked ticket, which I created, was a feature request. I closed it because this ticket had more activity & watchers. Please change this ticket to a feature request. I don't care if overriding uses the --sdk arg or a new --force-sdk flag.