Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

Ios #17

Closed
wants to merge 6 commits into from
Closed

Ios #17

wants to merge 6 commits into from

Conversation

tmcw
Copy link
Contributor

@tmcw tmcw commented Jan 29, 2014

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

@incanus
Copy link
Contributor

incanus commented Jan 29, 2014

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
Copy link
Contributor Author

tmcw commented Jan 29, 2014

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
Copy link
Contributor

incanus commented Jan 29, 2014

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.

@incanus incanus closed this Jan 29, 2014
@incanus incanus deleted the ios branch January 29, 2014 20:30
@incanus incanus mentioned this pull request Jan 29, 2014
@kkaefer
Copy link
Contributor

kkaefer commented Jan 29, 2014

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

@mb12 mb12 mentioned this pull request Oct 29, 2014
@PreviousTlx PreviousTlx mentioned this pull request Apr 13, 2018
This was referenced Aug 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants