objective-c: invalid readme or pathing error

[oddanderson]

The instructions say to include all objectivec/.h files and the .m files, however some files reference google/protobuf/.objc.h files which means they need to be included as well. In addition, the google/protobuf/*.objc.h/m files all use relative pathing for their import statements, which is a problem. Relative pathing should be avoided as much as possible with open-source objc files.

[thomasvl]

What's the problem with relative paths? Basically all includes are relative paths (they are done off the header search path). Yes, the common case is that they don't have a directory in the #include/import statement, but they are still relative. :)

[oddanderson]

I don't even have the code for this project anymore as I moved on from protobufs. But here's the scenario:

Create a project that uses protobufs. Then make that project open-source and create a cocoapod for it. If another project tries to use this cocoapod, it will fail to compile. The protobuf source files are located in a different directory under a different directory scheme than the original project via cocoapods, which is why it won't work.

[thomasvl]

@jcanizales

You seen any problems with this with cocoapods?

[thomasvl]

It almost sounds like the problem might be transitive include paths. i.e. if the project you make (that uses protos) is exposing protos via their headers; in which case, my guess would be the problem could be how that other project sets up it's pod to properly cascade the header dependency.

[jcanizales]

Create a project that uses protobufs. Then make that project open-source and create a cocoapod for it. If another project tries to use this cocoapod, it will fail to compile.

gRPC is an example of such project, that compiles alright, except for one specific scenario that might be what @oddanderson encountered. This is when Cocoapods is asked to generate the libraries as dynamic frameworks (instead of static libraries). This is necessary when one also uses pods written in Swift.

In that case Cocoapods does some things that don't work for a project that has headers in subdirectories, so I filed CocoaPods/CocoaPods#4605 . One of the gRPC users and I investigated it together and found a fix, but I haven't gotten the time to create a patch for Cocoapods. Nor have I tested any of it for Cocoapods 1.0.0-beta-3 (only 0.39).

[thomasvl]

Does this end up being the same root problem as we've been looking at with #1457?

[jcanizales]

That's what I referred to when I made my comment. I would think that's the problem Todd was facing.

[thomasvl]

Ok, then I'll close this as hopefully PR #1593 fixed it.