Mailing-List: contact issues-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 6 Jan 2015 16:58:34 +0000 (UTC)
From: "Geordie Jay (JIRA)" <jira@apache.org>
To: issues@cordova.apache.org
Message-ID: <JIRA.12765147.1420563373000.20604.1420563514463@Atlassian.JIRA>
In-Reply-To: <JIRA.12765147.1420563373000@Atlassian.JIRA>
References: <JIRA.12765147.1420563373000@Atlassian.JIRA>
 <JIRA.12765147.1420563373444@arcas>
Subject: [jira] [Updated] (CB-8254) Cordova build only uses xcconfig with
 --device flag (please also enable without)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CB-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geordie Jay updated CB-8254:
----------------------------
    Description: 
I have written a plugin in Swift that won't build with a deployment target < iOS 7.0. This breaks "cordova build ios":

Swift is unavailable on iOS earlier than 7.0; please set IPHONEOS_DEPLOYMENT_TARGET to 7.0 or later (currently it is '6.0').
(** BUILD FAILED **)


I know I can `cordova prepare ios` and manually add the changes to my xcode project, but as a plugin author this manual approach is unsatisfactory. Instead, I have added a hook to my plugin that adds the required options to build.xcconfig:

"IPHONEOS_DEPLOYMENT_TARGET = 7.0"
"SWIFT_OBJC_BRIDGING_HEADER = $SRCDIR/Bridging-Header.h"

This allows the code to build with `cordova build ios --device`


The problem is that `cordova build ios` alone doesn't pay any attention to the any of the three build.xcconfig files, because there is no -xcconfig option present for EMULATOR mode in the build script (see $PROJECT/platforms/ios/cordova/build).

-------

The solution:

The ideal solution would be the option to provide custom build options to `cordova prepare ios` that get directly integrated into the Xcode project. But I gather Apple doesn't provide us the option to edit Xcode projects outside of Xcode (and 3rd party solutions are far from reliable).


Which appears to leave us with two reasonable options:

(1) Provide another Xcode project for Swift plugins. Back maybe this isn't so reasonable after all: it's inconsistent, has the issue of setting a Bridging Header without knowing where it is in advance. What happens when we add a swift plugin to an existing project. Does the existing Xcode project get deleted?

(2) Add the same -xcconfig param to the EMULATOR section at the bottom of the `ios/cordova/build` file. This has the drawback of potentially confusing people when they open the Xcode project, but I think this is favourable to having the project not build at all from the command line.

Is there any reason that (2) couldn't be implemented effectively immediately?

  was:
I have written a plugin in Swift that won't build with a deployment target < iOS 7.0. This breaks "cordova build ios":

Swift is unavailable on iOS earlier than 7.0; please set IPHONEOS_DEPLOYMENT_TARGET to 7.0 or later (currently it is '6.0').

** BUILD FAILED **


I know I can `cordova prepare ios` and manually add the changes to my xcode project, but as a plugin author this manual approach is unsatisfactory. Instead, I have added a hook to my plugin that adds the required options to build.xcconfig:

"IPHONEOS_DEPLOYMENT_TARGET = 7.0"
"SWIFT_OBJC_BRIDGING_HEADER = $SRCDIR/Bridging-Header.h"

This allows the code to build with `cordova build ios --device`


The problem is that `cordova build ios` alone doesn't pay any attention to the any of the three build.xcconfig files, because there is no -xcconfig option present for EMULATOR mode in the build script (see $PROJECT/platforms/ios/cordova/build).

-------

The solution:

The ideal solution would be the option to provide custom build options to `cordova prepare ios` that get directly integrated into the Xcode project. But I gather Apple doesn't provide us the option to edit Xcode projects outside of Xcode (and 3rd party solutions are far from reliable).


Which appears to leave us with two reasonable options:

(1) Provide another Xcode project for Swift plugins. Back maybe this isn't so reasonable after all: it's inconsistent, has the issue of setting a Bridging Header without knowing where it is in advance. What happens when we add a swift plugin to an existing project. Does the existing Xcode project get deleted?

(2) Add the same -xcconfig param to the EMULATOR section at the bottom of the `ios/cordova/build` file. This has the drawback of potentially confusing people when they open the Xcode project, but I think this is favourable to having the project not build at all from the command line.

Is there any reason that (2) couldn't be implemented effectively immediately?

        Summary: Cordova build only uses xcconfig with --device flag (please also enable without)  (was: Cordova build only uses xcconfig when building for release)

> Cordova build only uses xcconfig with --device flag (please also enable without)
> --------------------------------------------------------------------------------
>
>                 Key: CB-8254
>                 URL: https://issues.apache.org/jira/browse/CB-8254
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: CLI, iOS
>    Affects Versions: 3.5.0, 4.1.3
>         Environment: All (iOS)
>            Reporter: Geordie Jay
>              Labels: easyfix
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I have written a plugin in Swift that won't build with a deployment target < iOS 7.0. This breaks "cordova build ios":
> Swift is unavailable on iOS earlier than 7.0; please set IPHONEOS_DEPLOYMENT_TARGET to 7.0 or later (currently it is '6.0').
> (** BUILD FAILED **)
> I know I can `cordova prepare ios` and manually add the changes to my xcode project, but as a plugin author this manual approach is unsatisfactory. Instead, I have added a hook to my plugin that adds the required options to build.xcconfig:
> "IPHONEOS_DEPLOYMENT_TARGET = 7.0"
> "SWIFT_OBJC_BRIDGING_HEADER = $SRCDIR/Bridging-Header.h"
> This allows the code to build with `cordova build ios --device`
> The problem is that `cordova build ios` alone doesn't pay any attention to the any of the three build.xcconfig files, because there is no -xcconfig option present for EMULATOR mode in the build script (see $PROJECT/platforms/ios/cordova/build).
> -------
> The solution:
> The ideal solution would be the option to provide custom build options to `cordova prepare ios` that get directly integrated into the Xcode project. But I gather Apple doesn't provide us the option to edit Xcode projects outside of Xcode (and 3rd party solutions are far from reliable).
> Which appears to leave us with two reasonable options:
> (1) Provide another Xcode project for Swift plugins. Back maybe this isn't so reasonable after all: it's inconsistent, has the issue of setting a Bridging Header without knowing where it is in advance. What happens when we add a swift plugin to an existing project. Does the existing Xcode project get deleted?
> (2) Add the same -xcconfig param to the EMULATOR section at the bottom of the `ios/cordova/build` file. This has the drawback of potentially confusing people when they open the Xcode project, but I think this is favourable to having the project not build at all from the command line.
> Is there any reason that (2) couldn't be implemented effectively immediately?


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@cordova.apache.org
For additional commands, e-mail: issues-help@cordova.apache.org