basic iOS operation

[incanus]

See https://github.com/mapbox/llmr-native/tree/ios, in particular the README.

[kkaefer]

CMake projects work differently in that you have to generate the project on your system because they hardcode paths (I can't build your project).

[kkaefer]

We don't need to stick with CMake as a build system generator. Maybe gyp has something to offer for us?

/cc @springmeyer

[incanus]

Excuse my ignorance here, but what are the benefits of a build system? It's not typically done on iOS & OS X projects, though Xcode of course works with many.

Maybe explain what we're looking to gain from it and I can help suggest how to best go with the Xcode flow? Because eventually, regardless, Xcode will be what iOS devs will be using.

[incanus]

The work happens in https://github.com/mapbox/llmr-native/blob/ios/ios/MBXViewController.mm @kkaefer. I will crack into CMake now to at least follow the current system.

[incanus]

Maybe explain what we're looking to gain from it and I can help suggest how to best go with the Xcode flow?

To put it another way, the work of porting to iOS is done in Xcode, not in source files directly -- this is the way you develop. Then I have to backport that to CMake.

Maybe once I have the sources files in CMake this will be easier, but I'm still going to (have to) work in Xcode to build & run on simulator & device, but then backport the discovered settings into CMake so they don't get clobbered again. It's creating more work from my point of view.

[incanus]

Some useful links on getting CMake to work with multi-arch sim/device builds and linking against iOS SDK frameworks instead of OS X ones:

• http://qt-project.org/forums/viewthread/36359
• http://cmake.3232098.n2.nabble.com/CMake-iOS-and-xib-compilation-td6812654.html
• https://code.google.com/p/ios-cmake/ (toolchain)
• https://www.mail-archive.com/cmake@cmake.org/msg38143.html (XIB compilation)

[springmeyer]

We don't need to stick with CMake as a build system generator. Maybe gyp has something to offer for us?

Cmake or GYP are both great. I prefer GYP due to greater familiarity with it, but we're going to be using both (OSRM uses CMAKE).

Maybe explain what we're looking to gain from it and I can help suggest how to best go with the Xcode flow?

A pure command line, cross-platform build system for the C++/cross-platform core is important. It allows for fast development and testing without the overhead of a GUI. For instance, if we want to run builds and tests on travis.ci we want to be able to do this on linux without xcode. And I'd personally love to be able to develop the C++ parts of llmr locally without needing XCode.

CMAKE/GYP can both generate XCode projects for the full application if that is what you want. The overhead of backporting new CXXFLAGS or linkflags, etc to the core build system is an overhead I think is worthwhile. But I can understand if this is painful for @incanus. Maybe what makes sense is a independent XCode project for the macosx/ios bits that depends on a static lib of llmr - but that static lib would only be built by cmake/gyp.

[incanus]

Maybe what makes sense is a independent XCode project for the macosx/ios bits that depends on a static lib of llmr - but that static lib would only be built by cmake/gyp.

Yeah, exactly what I was thinking. Then, the Xcode project(s) that I do can call out to CMake to build said static lib for linking into their apps.

I can see the clear benefits for the pure C++ part. But per the links above, using CMake with iOS seems to be a huge pain, and unlike @kkaefer's OS X demo app, which is just three sources files, a real Cocoa application or framework (OS X or iOS) has more nuance in the Xcode project than "Here's a pile of sources files, build them with these arguments." -- particularly when running on a device.

It's more like "Xcode, link in this outside lib and then spin me up an iOS app and debug environment" than "Here are my source files; compile them and then launch a command-line tool which opens an app window".

[incanus]

Ok, summarizing chat re: build systems just now with @springmeyer. Our conclusions:

• We want to have an Xcode-first GL SDK project for easiest use in iOS apps, easiest delving & collaboration with iOS devs for improving the project, building & running an app on multiple simulator and device platforms, and just otherwise doing things the way iOS development workflow works.
• We will use CMake or GYP (@springmeyer is researching the latter) -- but some build system -- to build the C++-specific parts and a minimal, machine-oriented Xcode project with static library product for inclusion in the above (i.e., a "subproject" in Xcode-speak). This is instead of an approach with the complexity of having the SDK Xcode project call out to CMake directly. Importantly, having CMake output an Xcode project lets folks working at the SDK level have the ability to edit the C++ directly and then just rebuild their iOS-level project -- project build dependencies will trickle down, rebuilding the static lib when needed.
• Getting CMake working with iOS the first time might be rather hard per the links above, but worthwhile to reach these end goals (I will be digging into this after @springmeyer has explored GYP a bit more).

The big disconnect was seeing Xcode as a pile of stuff to build vs. seeing it as workspace for everything going on at the Cocoa-native level. I think we have that cleared up.

[incanus]

I removed the ios branch for now to keep things clean and address #17. This gist has the meat of what's happening on iOS currently, and pending this ticket / #18 I'll get a proper iOS push going soon.

[incanus]

Closing this for now -- we've got everything going in other tickets, this branch is pulled, the gist is linked, and proper cross-platform work is happening. ⚡ ⚡ ⚡