Gyp

[springmeyer]

Moves the build to gyp instead of cmake. gyp has excellent support for building XCode projects and passing options down for specific settings.

Closes #18

Before merging:

• - quick eye of @kkaefer to kick the tires and tweak anything
• - work with @incanus tomorrow to ensure the correct options are default generated for an iOS subproject as per get libllmr.a building for ARM architectures #12
• - remove the cmake files

[kkaefer]

Still seems to reference a global gyp? I'm getting

~/Code/llmr/native ▶ make app
deps/run_gyp macosx/llmr-app.gyp -Goutput_dir=./out/ --depth=. -Icommon.gypi --generator-output=./build/macosx-make -f make
Traceback (most recent call last):
  File "deps/run_gyp", line 5, in <module>
    import gyp
ImportError: No module named gyp
make: *** [app] Error 1

[kkaefer]

a37f65a fixes path

[kkaefer]

This works for me; builds makefiles just fine. Can we get an Xcode project for the OS X app too? I'm using the built-in debugger interface in Xcode.

[kkaefer]

Ah sorry, there's make xapp. 👍

[springmeyer]

Nice catch on the path fix. Yes, make xapp. I added both a make based build and an xcode based built to ensure they both work (there are subtle things you need to do in the gyp files to fully support xcode). Happy to make that the default.

[incanus]

For the most part, this is looking great from an iOS / Xcode point of view. Comments:

• I had to ./configure --boost=/usr/local/Cellar/boost/1.55.0 to get it to build in the Xcode project. The OS X build, not necessarily being Xcode-driven, didn't need the argument. Any way we could find and/or default to that, since that's gonna be easier for OS X-based iOS devs?
• Builds ok for OS X, but more importantly, simulator (i386 & x86_64) and device (armv7, armv7s, and armv8 64-bit).
• There's some funkiness with @springmeyer's attempts at a dual OS X / iOS project which I should be able to rectify before we merge. But I don't necessarily see the point in having OS X in there if 1) it's not a real focus of the platform, but rather just a testbed and 2) iOS devs aren't going to really need it. I'd rather stick to the straight-up GYP build system and/or make xapp that we have for OS X until such time as we grow out of GLFW and make a real OS X stab. Thoughts?
• We will need the header files in the llmr.xcodeproj as well. In an ideal scenario, iOS devs aren't going to want to modify their include paths and bring in a dependent subproject like llmr.xcodeproj -- this should all happen together. Having the headers in a Headers group just like the Source one now would be perfect. The approach you want is linking against the static lib and having easy access to the headers right in Xcode. @springmeyer do you have a good idea of how to do this? I will start to look.
• The C flags and preprocessor macros look ok.

[springmeyer]

• covered on chat with @incanus that the /usr/local default for boost should work for all targets, so something is fishy - he is looking closer.

There's some funkiness with @springmeyer's attempts at a dual OS X / iOS project which I should be able to rectify before we merge.

Can you help me replicate, or share the errors?

But I don't necessarily see the point in having OS X in there if 1) it's not a real focus of the platform, but rather just a testbed and 2) iOS devs aren't going to really need it. I'd rather stick to the straight-up GYP build system and/or make xapp that we have for OS X until such time as we grow out of GLFW and make a real OS X stab. Thoughts?

We should support both platforms. The way to do this best is the question. I'm positive they can coexist. So, we either need to get the conditions inside a single gyp file just right for both targets or just split off two gyp files. I don't have a preference here. What do you propose?

We will need the header files in the llmr.xcodeproj as well.

The include paths to the header files should be showing up. Sounds like that is not enough? You need the actual listing of files to be somehow stored in the xcode project? I'm not aware if gyp can/will auto-build xcode projects like this - needs some research.

In an ideal scenario, iOS devs aren't going to want to modify their include paths and bring in a dependent subproject like llmr.xcodeproj -- this should all happen together. Having the headers in a Headers group just like the Source one now would be perfect.

Yes, include paths should be there automatically in the generated project. If not its a bug.
As far as references to the headers themselves: see above - don't know how to do this with gyp, but we can research it.

[incanus]

There's some funkiness with @springmeyer's attempts at a dual OS X / iOS project which I should be able to rectify before we merge.

Can you help me replicate, or share the errors?

The supported platforms looked weird -- these should not be in the same target. That is, the end Xcode project should have two targets in the top-left pulldown -- one for OS X and one for iOS, each supporting the respective platform. I will see if I can get GYP to do this.

We should support both platforms. The way to do this best is the question. I'm positive they can coexist. So, we either need to get the conditions inside a single gyp file just right for both targets or just split off two gyp files. I don't have a preference here. What do you propose?

I think solving the above can result in an Xcode project with two targets, one for each platform. As for the make name to use, probably should just default to no argument and build the Xcode project that contains both.

The include paths to the header files should be showing up. Sounds like that is not enough? You need the actual listing of files to be somehow stored in the xcode project? I'm not aware if gyp can/will auto-build xcode projects like this - needs some research.

Yes, we need the files in Xcode. This is for code completion, type checking, easy header reading in the IDE, etc.

[springmeyer]

the end Xcode project should have two targets in the top-left pulldown

This should be working now - take a look a let me know if we are closer. Do make xcode now (see README).

[incanus]

Looking better. More notes.

• iOS still fails out of the box for simulator as it can't find Boost. I don't understand yet why this is the case when it works on OS X. Will dig. It builds ok for ARM devices.
• We are now building only 64-bit for OS X, which is probably alright.
• We are deploying down to 10.8, which requires 64-bit anyway.
• We don't need the Copy Headers build phase as there is no place to copy them to. This would differ if we were shipping a product that needed to include the headers, but bringing in the dependent Xcode project is all we need. The headers just need to be referenced in Xcode, which they are -- I will clean up the group name that they show up under, though to match convention.
• The targets check out awesome now in Xcode.

[incanus]

We also will need to upgrade the Xcode project format or users of it will get this annoying nag:

Here is what it does -- I will look at adding these:

[springmeyer]

all done, closing this, merge of clean/rebased branch at #28