Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-12368] CLI: There's no way to set the build SDK from the new CLI

GitHub Issuen/a
TypeBug
PriorityLow
StatusOpen
ResolutionUnresolved
Affected Version/sRelease 3.0.0
Fix Version/sn/a
ComponentsCLI
Labelscb-tooling, ft
ReporterTony Lukasavage
AssigneeChris Barber
Created2013-01-22T03:08:13.000+0000
Updated2016-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

  1. Ingo Muschenetz 2014-08-12

    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?
  2. Tony Lukasavage 2014-08-12

    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.
  3. Tim Poulsen 2014-08-25

    As a workaround: What I found while investigating the linked ticket is that if you remove the tag from the tiapp.xml then your app will be built using either the version selected with ti sdk select or the version you specify with the --sdk arg. In either case, whatever is set with ti sdk select is used by the CLI to bootstrap.
  4. Chris Barber 2014-08-25

    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.
  5. Tim Poulsen 2014-08-25

    Not nearly so involved, I just submitted https://github.com/appcelerator/titanium_mobile/pull/5987 Functional review:
       var win = Ti.UI.createWindow({
       	backgroundColor: 'white'
       });
       var lbl = Ti.UI.createLabel({
           text: "Titanium version: " + Ti.version,
           wordWrap: true,
           top: 20, left: 10, right: 10
       });
       win.add(lbl);
       win.open();
       
    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.
  6. Chris Barber 2014-08-25

    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.
  7. Tim Poulsen 2014-08-26

    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.

JSON Source