Build into include/GRMustache in the built products directory.

[samdeane]

There seems to be a de-facto standard to build Mac/iOS static library headers into include/$(PRODUCT_NAME).

This allows a framework-style #import <GRMustache/GRMustache.h>.

It also apparently removes the need to set a custom include search path, since "$(TARGET_BUILD_DIR)/include" is apparently in there by default (I'm not certain about this - I've been told that it's true, but I've seen situations where you seem to need to manually add it).

This pull request includes the relevant change for the Mac target, since that's the one I'm using right now. It would be simple enough to change the iOS one too of course (happy to do that if you feel inclined to accept the patch).

[samdeane]

Here's a relevant excerpt from an Apple tech note:

Your library’s headers are automatically included in your application’s header search path, as they are inside the built product directory’s include directory. Since your library puts its headers in a further directory named after its PRODUCT_NAME build setting, you need to include that directory in your include or import statements when importing that library’s headers. In your application’s source code you should import your library’s headers like this:

import "LibraryName/HeaderName.h"

where LibraryName is the name of your library (the value of its PRODUCT_NAME build setting) and HeaderName is the name of the header you want to import.

http://developer.apple.com/library/mac/#technotes/iOSStaticLibraries/Articles/configuration.html

There are also various blog posts out there that suggest setting things up this way. I found one here with some quick Googling, but I'm sure I've come across others in the past.

http://www.blackdogfoundry.com/blog/creating-a-library-to-be-shared-between-ios-and-mac-os-x/

[samdeane]

NB - normally I would set the public headers folder path setting to actually be "include/$(PRODUCT_NAME)", but your target name includes "6-MacOS", the product name is derived from the target name, so that doesn't work.

Personally I'd prefer that the library just built as libGRMustache for both platforms, and would set PRODUCT_NAME to be just GRMustache for all the library targets. Arguably that's a matter of person preference though, so I didn't touch it here.

[samdeane]

Another reference, this time to the instructions for building a library (more relevant...)

http://developer.apple.com/library/mac/#technotes/iOSStaticLibraries/Articles/creating.html#//apple_ref/doc/uid/TP40012554-CH2-SW1

[groue]

Hi, Sam.

I'm not familiar enough with Cocoa development: I'm more an iOS guy. And indeed, since there is no easy support for Frameworks in iOS, I'm not familiar with them.

Today, OSX developers have three options:

• CocoaPods
• static lib (not built via Xcode, but via the Makefile - maybe broken by your commit)
• raw sources

I know (through commits added to some forks) that some people integrate the raw GRMustache.xcodeproj project in their projects: they tweak the project here and there in order to make it integrate well. None has ever opened any issue, so the subject has always remained fuzzy to me. Maybe you belong to those people?

I'm quite keen to improve GRMustache integration for OSX developers. But what is your goal? Is it to ship a complete framework with the distribution? Is it to ease the drag&drop of the GRMustache.xcodeproj in their own project? What is the best option? Are the two of them desirable? Is there a third one I didn't foresee yet? What about adding a section to the Guides/installation.md file?

About the naming of static libs (libGRMustache6-iOS.a, libGRMustache6-MacOS.a), here is the rationale: the major version number is there to make sure that people who pull a new major version notice the major version change (since a new major version implies incompatibilities). And the platform suffix... I'm not sure it is needed anymore, actually. I don't know if one can build a static lib with both iOS and OSX.

I'm quite open to your suggestions. Please make sure that I, and the end user, are taken by the hand :-)

[samdeane]

Hi,

Yes, I add the project to Xcode and build it on demand, like this:

The issue when doing this is the same for iOS and OS X - namely, how to find the header files, and how to find the built library.

The way you have things set up currently, it will build into the Build Products folder like this:

This is a slight pain as it requires this sort of thing to be added to the build settings:

HEADER_SEARCH_PATHS = $(inherited) "$(TARGET_BUILD_DIR)/usr/local/include"

If you built the headers instead to the default location "includes/$(PRODUCT_NAME)", Xcode should pick up the headers automatically.

This allows people to treat GRMustache as if it was a framework for the purposes of #import. They can write #import <GRMustache/GRMustache.h> and Xcode will find the headers correctly.

[groue]

OK, I get it. And your commit fixes this?

[groue]

@samdeane Hi Sam, any hint about whether I should accept your pull request as it is, its caveats, if any, and how I would test it?

[groue]

My problem, Sam, is that I don't exactly know how to spot the difference. More precisely, I do not understand your sentence:

This allows people to treat GRMustache as if it was a framework for the purposes of #import. They can write #import and Xcode will find the headers correctly.

Are you talking about #import "GRMustache.h" (current situation, which requires adding a custom include search path, if I understand well) vs. #import <GRMustache.h> (that would be automatically brought by your change, if I understand well) ?

[samdeane]

Hi, sorry I've been quiet - have been moving house and am still without broadband.

I'm talking about #import <GRMustache/GRMustache.h>, which is the standard form for importing things from frameworks.

My commit makes this possible for the Mac target. I didn't do it for the iOS target (as I wasn't using it), but it would be easy to make the two consistent.

[groue]

I'm talking about #import , which is the standard form for importing things from frameworks. My commit makes this possible for the Mac target.

Come on, Sam, #import is also the way to import GRMustache as it is now.

So your sentence doesn't help me spot the difference between the current situation and the one after applying your change.

And until I spot any difference, there is no resolution of this PR. I'm not the kind of guy who blindly accepts PRs, you already know that.

So please let me help you, and state what I'm currently understanding from your comments:

1. You say that when the user adds the GRMustache project to his own OSX project, the current GRMustache.xcodeproj requires the user to fiddle with HEADER_SEARCH_PATHS in the setting of his own project. After HEADER_SEARCH_PATHS has been tweaked, the user can write #import "GRMustache.h" (with quotes).
2. You say that this situation is painful, for two reasons: a. The HEADER_SEARCH_PATHS fiddling could be avoided. b. The import statement should use angle brackets: #import <GRMustache.h> .
3. You say that your pull request fixes both those annoyances for OSX targets, which means that after your patch is applied: a. User doesn't have to tweak the project settings. b. The import statement can use angle brackets. Both points out of the box.
4. You say that you don't have the slightest idea if your patch would fix, break, or be neutral with iOS targets, because you don't really care about iOS.

If any of those statements is wrong in any way, please answer clearly. Thanks!

I'm sure we'll eventually find a solution that fits OSX developers like you, who drag the GRMustache project in their own project. We also have to fit iOS developers who do the same. And above all we have to fit developers that use the currently recommended ways to import GRMustache.

[groue]

Hi, sorry I've been quiet - have been moving house and am still without broadband.

It's a hot summer here in France, so slow pace is OK :sunglasses:

[groue]

OK. I'm closing this PR. I'm sorry I could never fully understand the trouble here (and check it by myself).