Build without Cocoapods?

[Air-Craft]

I'm trying to avoid using CocoaPods and have the BK files directly in my Xcode project but I get build errors based on the use of brackets "<...>" in the BK internal imports. I've tried all header search paths possibilities I think ("user", "framework" and "library") both with and without "recursive". From what I read it seems that within a framework one should use quotes and the brackets are only for external frameworks. Is that correct? Any ideas?

[Mazyod]

If you're main goal is to avoid CocoaPods, simply drag the BlockKit project into your app project. If it is imported as a single file, you have to upgrade your app's project to a workspace first. This way, the code will be there, but a static library will be built and linked to your app with the proper settings in place. (Add as target dependency, then link against libraries, and the header path search is needed).

[Air-Craft]

Regardless, I believe the files are still being referenced incorrectly and it's just being covered over by the nature of the settings. Fixing it would make it work in all contexts.

[Mazyod]

@Club15CC I don't think there is any problem with how they are referenced. There are certain headers that are public headers, which are not part of the source. These headers you must discard if you want to just add the source files to the project.

[Air-Craft]

There are two issues, IIRC, one is what looks like imports that haven't been updated after a reorganisation of the files. For example...

BlocksKit+MessageUI.h:
#import <BlocksKit/MFMailComposeViewController+BlocksKit.h>

That file is actually in /BlocksKit/MessageUI/... I don't know why you get away with this in the Pod/static-lib settings but you don't otherwise.

The second issue is using framework includes (<>) to your own source from within your source. I'm not certain about this but I thought angled brackets are for including other framework's headers and quotes were for internal linkage.

In the end there's no reason it can't work in both and personally I've grown to prefer keeping as much source in my project as possible unless there is compelling reason to do otherwise (such as building ffi in previous BK versions).

[Mazyod]

Regarding your first issue, that is exactly my point. That file is a public header file, you should only use if if you are linking against the static library. Delete it if you're not, and include the files using quotations.

Regarding the second issue, yes, there is no reason at all, and it does work for both. It is just structured more conveniently for developers who want to build it as a static lib. But, by carefully including only the required source files, it will work.

[Air-Craft]

Sorry, some of that got cut out thinking it was HTML. The paths in BlocksKit+MessageUI.h simply don't exist:
BlocksKit/MFMailComposeViewController+BlocksKit.h -- where is this file?

Are you saying that if I want to include the code directly I need to manually import each and every blocks kit file I use rather than BlocksKit.h etc?

[Mazyod]

Exactly :) You need to import each and every single file, or create your own header that imports them with quotations

[Air-Craft]

But you wouldn't need to if you simply made the fixes.

On Thu, Aug 7, 2014 at 9:06 AM, Mazyad Alabduljaleel <
notifications@github.com> wrote:

Exactly :) You need to import each and every single file, or create your
own header that imports them with quotations

—
Reply to this email directly or view it on GitHub
#242 (comment)
.

[Mazyod]

if you change the angel brackets to quotations, people linking against the static lib like me will start to complain.

[Air-Craft]

Ok that’s fair enough but what about fixing the paths, or does the static build move the header files around or something?

On 7 Aug 2014, at 09:12, Mazyad Alabduljaleel notifications@github.com wrote:

if you have the angel brackets to quotations, people using linking against the static lib like me will start to complain.

—
Reply to this email directly or view it on GitHub.

[Mazyod]

Oh, I see what you're saying. Yeah, it's as you said. The public headers are copied into a flat structure, which is incompatible with the structure of the source files. I can't think of a way that satisfies both developers, compiling the source and including the lib, with this one.

The best solution to this problem might be to create another set of header files that reference the appropriate paths and add them to the repo. You can script it to avoid the mundane task.

[Air-Craft]

Yeah, ok. I get it now. That’s doable. Static lib might be the way forward then. It’s just Pods have cost me more time than they have saved me so I abandoned them when BlocksKit removed the ffi dependency. Check out “Giternal” sometime. It’s my favourite solution for iOS. Thanks for the help...

On 7 Aug 2014, at 09:24, Mazyad Alabduljaleel notifications@github.com wrote:

Oh, I see what you're saying. Yeah, it's as you said. The public headers are copied into a flat structure, which is incompatible with the structure of the source files. I can't think of a way that satisfies both developers, compiling the source and including the lib, with this one.

The best solution to this problem might be to create another set of header files that reference the appropriate paths and add them to the repo. You can script it to avoid the mundane task.

—
Reply to this email directly or view it on GitHub.

[Mazyod]

No problem. I had problems with cocoaPods, I don't use it in my projects. I use git submodules + workspaces, and everything works fluently. (Although I figured out later it was Ruby's fault, not CocoaPods).

[zwaldowski]

The supported ways to use BlocksKit without CocoaPods are either via the static library release, or by embedding the Xcode project into yours to and build the static library that way. The filesystem arrangement of the files is not 1:1 with the release configuration; the filesystem arrangement is intended to ease development and not distribution. Thanks for the help, @Mazyod.