Following Apple's guidelines for iOS Static Libraries

[evandelaney]

Cocoa Lumberjack Team,

This pull request may not interest you given the continued effort put into maintaining the CocoaPods spec, but I'm optimistic that there are others like me that prefer to use bare git submodules and a static library.

I've reworked the iOS static library project to follow Apple's recommendations in this tech note. If the Apple link changes, then you should be able to find it by searching the phrase "Using Static Libraries on iOS." This puts exported headers in an expected place (however much water that may hold), and does not require changes to a target app's Search Paths build settings.

I've found these modifications to the Lumberjack static lib helpful for my projects. Maybe others will, too.

I welcome discussion about why you think this is a beneficial or not-so-great pull request; this is my first contribution to the community and I'm hoping to learn from the experience. I've enjoyed using CocoaLumberjack, and I'm hoping this might be a small way to show my support.

[rivera-ernesto]

This import can (and probably should) stay unchanged. The reason being that if "search headers path" is properly configured then <...> imports should work.

Also it better isolates library headers, is less tied to particular directories/paths and migrating to/from CocoaPods<->Static Library is easier.

Apple's documentation chose to use "..." without making it a guideline. More info here.

[rivera-ernesto]

I was about to propose to abandoning the Static Library as recent development has not been "back-ported" for it (CLI and soon ASL Capture for instance).

If someone however finds it useful and wants to maintain it then great. The code however should stay as CocoaPods/Static Library-agnostic as possible.

[evandelaney]

Your comments about angle brackets above don't exactly make sense to me - It's a little over my depth. Is there a resource where I could learn more? I'd be happy to maintain the static library for iOS.

[rivera-ernesto]

Just added a link to the first comment.

[rivera-ernesto]

@evandelaney after checking this (and this) do you still prefer to change the imports before we merge this?

[evandelaney]

Sorry, still getting my bearings. Gimme until the end of the week, please.

[rivera-ernesto]

Sure, not meant to push you, it was just a ping ;)

[evandelaney]

Summary:
Yes, leaving the angle brackets is okay.

Discussion:
So, I better understand #import "..." vs. #import <...> from then links you posted (thank you!), but I'm still unclear on how angle brackets in Lumberjack.h effect or require the Header Search Path build setting.

The suggested changes have modified the Lumberjack.xcodeproj "Build Phases," and now the .h files are copied into Build/Products/<build config name>-<platform>/include/<target name>/. So, for example this results in Build/Products/Debug-iphoneos/include/Lumberjack/. When I bring the Lumberjack.xcodeproj into a workspace, the workspace target's Build Settings don't need to be changed; any source file can #import "Lumberjack/Lumberjack.h", build, and it works.

There is no change in this behavior if Lumberjack.h uses quotes or angle brackets for import.

The behavior / use case outlined above is what my intention was behind this pull request, but I still feel like I may have missed something important around #import "..." and #import <...>.

(Sorry for the delay on this, I got slammed with work)

[rivera-ernesto]

Well the idea of using #import <.../...> is to encapsulate libraries and their headers and keep them separate from the host application. All references from outside CocoaLumberjack should use those imports and they will work with both a static framework and CocoaPods and that's the reason why you use the same syntax for any Apple framework and library.

More important with this syntax any header conflict can be solved without touching any source file import, but by simple adjusting the project's HEADER_SEARCH_PATHS.

On the other hand references inside your project use #import "..." because the file and the header it references live in the same project/directory/namespace at all times. That's also why code inside CocoaLumberjack or inside any Apple library uses this syntax.

[bpoplauschi]

Gentle reminder guys

[rivera-ernesto]

Just checked again my two comments.

• The changes look fine on the second one Following Apple's guidelines for iOS Static Libraries #249 (comment) .
• I still think the first one Following Apple's guidelines for iOS Static Libraries #249 (comment) should be #import <.../...> as with any library import.

[evandelaney]

@rivera-ernesto I've pushed the suggested change, and it certainly won't upset me if you still feel like these changes aren't appropriate for the project given the effort put into supporting CocoaPods. I've come away with a better understanding about #import<...> vs #import "..."

[rivera-ernesto]

Looks good. Thanks!