CODEWITHSUNDEEP
ioscore-plotxcode5.1
user3465263
user3465263

Reputation: 1

CorePlot support for arm64?

In Core-plot 1.4, I can use the pre-built Binaries/iOS/libCorePlot-CocoaTouch.a library in my iOS app, but only if I delete "arm64" as a valid architecture in BuildSettings/ValidArchitecture script.

Can I rebuild this library to include arm64 using Source/framework/CorePlot-CocoaTouch.xcodeproj, setting its BuildSetting/Architecture to arm64?

The same question applies to CorePlot1.5.1. In 1.5.1, where can I easily find the CorePlotHeaders folder, which conveniently is Binaries/iOS/ in 1.4.

When I build, I get the Debug products, but do not see Release products in places where Build Settings says they should be. What am I (still new'ish to Xcode5) missing?

Why would I want to include CorePlot as a dependent item, rather than simply include its static library in my Xcode project app? The latter is simpler.

Upvotes: 0

Views: 1951

Answers (1)

Eric Skroch
Eric Skroch

Reputation: 27381

  1. Can I rebuild this library to include arm64 using Source/framework/CorePlot-CocoaTouch.xcodeproj, setting its BuildSetting/Architecture to arm64?

    Yes. Build the "Universal Library" target to make a complete release binary with both device and simulator code.

  2. The same question applies to CorePlot1.5.1. In 1.5.1, where can I easily find the CorePlotHeaders folder, which conveniently is Binaries/iOS/ in 1.4.

    The headers are in the same place in the 1.5 and 1.5.1 release folders, too.

  3. When I build, I get the Debug products, but do not see Release products in places where Build Settings says they should be. What am I (still new'ish to Xcode5) missing?

    This is determined by the selected "scheme". By default, building or running makes a debug version while profiling or archiving makes a release version.

  4. Why would I want to include CorePlot as a dependent item, rather than simply include its static library in my Xcode project app?

    You would use the dependent library build if you were keeping up with the latest code from Github or using your own private fork. You can always build a static library from source (see question #1, above), but if the Core Plot code is changing often, its easier to include the project directly.

Upvotes: 4

Related Questions