I will take look into detecting incompatible ARC files that will potentially give compiler errors.
So far what I had found is to look if code is using invalid functions (i.e. retain and release) Taking into consideration that file could be using macro to have dual path based on #if !__has_feature(objc_arc) --Carlos On Friday, June 21, 2013, Filip Maj wrote: > That would be cool, have at it Carlos :D > > On 6/21/13 12:11 PM, "Carlos Santana" <csantan...@gmail.com> wrote: > > >+1 on the be able to inject compiler options per file from xml > > > >On the same area, what about coding a small script/tool to analyze a > >plugin > >folder and generate the plugin.xml section containing the list of files > >that need the flag? > > > >--Carlos > > > > > >On Fri, Jun 21, 2013 at 3:00 PM, Shazron <shaz...@gmail.com> wrote: > > > >> Also, Andrew Grieve did propose it here in proposal #2: > >> > >> > >> > http://markmail.org/thread/tskkqinboyp5cjdg#query:+page:1+mid:ojea6mtsrtx > >>x6f2a+state:results > >> > >> Awesome, I'll file it > >> > >> > >> On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj <f...@adobe.com> wrote: > >> > >> > Sweet, let's file an issue as a feature request for this and I'll do > >>my > >> > best to get this in time for 3.0. > >> > > >> > On 6/21/13 11:54 AM, "Shazron" <shaz...@gmail.com> wrote: > >> > > >> > >Of course it should be considered. We did discuss this briefly, but I > >> > >don't > >> > >think we added it as a feature request in time for 3.0.0. > >> > >What I did recommend however, is for plugins to use the > >> > >__has_feature(objc_arc) macro to support both ARC and non-ARC. This > >>way, > >> > >including it in any kind of project setting it would work - without > >> adding > >> > >this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project > >> > >template (for plugin compatibility reasons), but in 3.0.0 we are > >> enabling > >> > >it in the default template: > >> https://issues.apache.org/jira/browse/CB-2180 > >> > > > >> > >More info here: > >> > > > >> > > >> > >> > http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counti > >>n > >> > >g-arc-and-cordova-plugins/ > >> > > > >> > >For pre-compiled binaries it's no problem (say the TestFlightSDK > >>ships > >> > >with > >> > >libTestFlight.a), and for small plugins to convert to use the macro, > >> but I > >> > >can see it being a problem if we had to include the Facebook SDK with > >> its > >> > >gajillion files that may or may not be ARC (since converting them may > >> be a > >> > >maintenance nightmare for newer versions). > >> > > > >> > >For that last scenario, I would recommend having that new compiler > >>flags > >> > >attribute. > >> > > > >> > > > >> > >On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes <aa...@stasis.org> > >> wrote: > >> > > > >> > >> I've really been enjoying the cordova cli/plugin.xml definition. > >> > >> > >> > >> I've been porting a bunch of old plugins to work with plugman's > >> > >>plugin.xml > >> > >> definition. Generally it's been going well, however one problem > >>I've > >> > >>come > >> > >> across a few times particularly when trying to apply it to old > >>code or > >> > >> adapting 3rd party code is that the code isn't ARC compliant. The > >> > >> preference would obviously be to make the code arc-compliant, but > >>not > >> > >>being > >> > >> a pro in objective c, it's often easier to just add '-fno-objc-arc' > >> as a > >> > >> compiler flag for the file in xcode. > >> > >> > >> > >> It would be great to add as an option for iOS builders, I'm > >>thinking > >> > >> something like: > -- Carlos Santana <csantan...@gmail.com>
