bazel: Bazel fails if I #import while XCode is fine with it.

@lswith we are also doing this at Pinterest literally right now (porting our 40ish cocopods over). We ended up making a workspace rule called new_pod_repository ( https://bazel.build/versions/master/docs/be/workspace.html ). Example:

new_pod_repository(
  name = "PINOperation",
  url = "https://github.com/pinterest/PINOperation/archive/1.0.3.zip",
  owner = "@ios-cx",
  strip_prefix = "PINOperation-1.0.3",
)

During workspace loading we pull down the repo and then automatically convert the Podspec into a BUILD file using a Swift program. Then we can just refer to these as a dep like @PINOperation//:PINOperation

By making each cocoapod a separate workspace rule you get <> imports that work in the same way (assuming you move the headers around in the same way that cocoapods does) + it also semantically to be a workspace makes sense as a workspace rule since we’re getting something from a third-party.

The goal is to push as much as we can to our automated Podspec -> BUILD tool so it’s easy to add/upgrade/remove pods

This is exactly what I need!!! I would love if you open source this! It would be a lot of help. I’m happy to help contribute as well On Fri, 5 May 2017 at 6:58 am, Brandon Kase notifications@github.com wrote:

@lswith https://github.com/lswith we are also doing this at Pinterest literally right now (porting our 40ish cocopods over). We ended up making a workspace rule called new_pod_repository ( https://bazel.build/versions/master/docs/be/workspace.html ). Example:

new_pod_repository( name = “PINOperation”, url = “https://github.com/pinterest/PINOperation/archive/1.0.3.zip”, owner = “@ios-cx”, strip_prefix = “PINOperation-1.0.3”, )

During workspace loading we pull down the repo and then automatically convert the Podspec into a BUILD file using a Swift program. Then we can just refer to these as a dep like @PINOperation//:PINOperation

By making each cocoapod a separate workspace rule you get <> imports that work in the same way (assuming you move the headers around in the same way that cocoapods does) + it also semantically to be a workspace makes sense as a workspace rule since we’re getting something from a third-party.

The goal is to push as much as we can to our automated Podspec -> BUILD tool so it’s easy to add/upgrade/remove pods

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bazelbuild/bazel/issues/306#issuecomment-299306945, or mute the thread https://github.com/notifications/unsubscribe-auth/AA-K-yf_8naMmz4Wit1hEhkTMWKXx_Cpks5r2ju8gaJpZM4FYlDO .

+1 - It’d be awesome if this worked out of the box, because a large subset of objc code uses angle bracket includes ( see www.cocoapods.com ) None the less, I think there are a few ways to overcome this issue:

1. Replicate the directory structure made in pod install:

In short, move the source code into directory structure the same way that cocoapods did: copy and paste them into genfiles. i.e. genfiles/SomeProject/SomeHeader.h. Then, you can simply -isystem $(GENDIR) and the angle brackets will resolve to the correct path. This may not work for all cases and have other complexities.

1. Use clang’s built in virtual file system, VFS.

VFS can alias the <> includes to their real location. Here is the RFC http://clang-developers.42468.n3.nabble.com/RFC-A-virtual-file-system-for-clang-td4037693.html .

The drawback here, in my testing of this, the VFS needs an absolute path to the build directory: the per compilation bazel sandbox. I’m already compiling .o files with a shell script and passing them to objc_library, so it would be easy to generate a VFS overlay containing the absolute path of the sandbox.

2a) Use VFS and disable the sandbox. This way, you wouldn’t need to have custom compiler invocations, and can generate a VFS overlay where the absolute path is the source directory.