Ios

[tmcw]

Let's try sticking to branches we can merge, unless we want to create a llmr-ios repo.

[incanus]

Agreed in principle, but same problem as over in llmr -- @kkaefer needed to see my work and do we really want to get into sharing zip files of source code on Dropbox? See also #13 -- I was faced with the prospect of learning/wranging CMake and completely redoing my xcodeproj just to get him a preview of the code.

Can't we just git push origin :ios later and remove it?

[tmcw]

I was faced with the prospect of learning/wranging CMake

Doesn't cmake .. -G Xcode just work?

This branch is basically the other branch, plus mergeable additions: why doe sit totally rewrite README.md? What about this breaks the codebase enough that it needs to be in a separate branch?

[incanus]

This is a temporary branch, meant to be deleted once I figured out the build system, which was a side goal to me getting code into @kkaefer's hands as soon as possible before I had to get offline + us being separated by nine hours and per his chat request:

cool, can you commit what you have when you head out so I can try it tomorrow morning?

I modified the README to orient him to how to get the project going, which is what README is for.

It was a separate branch because it built on the xcode/llmr.xcodeproj, which is in .gitignore for master and would not get included because it's typically part of the CMake output.

I don't know if cmake just works. The first time I did it after attempting to pull down the latest master, it clobbered my xcodeproj and I had to rebuild it from scratch (about 30 minutes lost work).

When sitting down to try to get an iOS port working as quick as possible, learning a build system (the reasons for I'm still unclear of) before getting to any actual coding seemed like a poor use of time. I'm digging into it now though and might be able to clean it up. I'm not opposed to using CMake (providing we need it) but kicking off a port to iOS sprint with learn arbitrary build system because why? didn't seem like a great start.

[kkaefer]

Sorry @incanus, I should have clarified how CMake works:

The truth is always in the CMakeLists.txt files. The generated project files (Makefiles, Xcode project files are never modified (or committed to a repository). They are automatically generated from the CMakeLists.txt files. Also, Xcode and Makefiles automatically update themselves when you build a target, so you don't have to rerun cmake all the time.

I'm not sure whether building iOS applications and cross-compiling is easy to do with CMake, but there are a few projects like https://code.google.com/p/ios-cmake/

I chose CMake because it seemed like a good way to build both Xcode projects and Makefiles (for Linux) and I've used it heavily in previous university projects that ran on Windows, Mac and Linux. However, I'm not tied to CMake and we can switch to whatever build system covers our needs. See #18 #12