Conversation
8437c0d to
80e6316
Compare
80e6316 to
07faa64
Compare
|
Yay! |
matteblair
left a comment
There was a problem hiding this comment.
Building for iOS seems to work, and using CMake to configure these files is better than the makefile steps that I had. However there are a couple issues with these changes:
- After running CMake I'm left with untracked files in git:
platforms/ios/Tangram.xcworkspace/contents.xcworkspacedata
platforms/ios/demo/TangramDemo.xcodeproj/project.pbxproj
Presumably because git recorded these files being moved to the templates folder. We could duplicate these files in their old locations or gitignore them entirely, but this leads into ...
- Changes to the demo Xcode project will be clobbered by CMake. The demo project isn't generated by CMake, it's generated and modified by Xcode like a typical iOS project. If we "configure" this file from a template then the template is where changes get preserved, but there's no easy way to update the template when we make changes to the project.
There may be a way to work around 2, but until we find it we can't merge this :\
| jazzy --config jazzy.yml | ||
|
|
||
|
|
||
|
|
|
Ok no hurry for me - still figuring out how to build things for ios. So it's good that this part works for me :) I think we could keep the default files with relative build dirs in the repo. This way it's easy to see when our changes should be committed. |
|
That might be a good compromise. The |
This allows setting a custom IOS_BUILD_DIR in Makefile. Very handy for developing on linux and osx at the same time when osx mounts the source directory from linux - so that the build output is not written over the network.