Building iOS static frameworks

[Steve Dee]

I've just created this enhancement: https://github.com/google/bazel/issues/365

I'm assuming that that's a ways off. In the meantime, I'm planning to do iOS builds using a script that makes heavy use of bazel. I imagine the steps are something like this:

1. For each architecture, bazel build $(bazel query 'kind(.*_library, deps(//my:target))'). Then combine all the dependent libraries into one big .a? Or package them separately? Still need to do some tests to find out what works here.
2. Create a skeleton framework dir with appropriate symlinks and subdirectories.
3. lipo the resulting libraries together into the framework dir.
4. Copy the headers into the appropriate place in the framework dir -- I suppose these could be extracted via bazel query 'labels(hdrs, //my:target)', but I'm not sure how to get them from target syntax to a fs path just yet.

Feedback is much appreciated, especially on steps 1 and 4.

Regarding step 1: the main source of confusion is how to handle libraries that depend on other libraries in my workspace. I suppose in the end I'd want a single static library per framework that includes all dependent libraries but not system libraries or frameworks. Maybe I could write one big library target by exporting my sources as filegroups and saying srcs = [":my_srcs"] rather than deps = [":my_lib"]? Seems non-ideal, but I don't know of any alternatives.

[Steve Dee]

Here's an artifact from my progress so far, a script that makes a fat iOS library with all dependencies bundled:

https://gist.github.com/mrdomino/4421c3103147627925b0

bazel-bin is obviously not a great place to stick the output, but I couldn't think of a better place off the top of my head. ios_multi_cpus seems like it should do something along those lines, but I couldn't get that working, so I didn't bother. It's also arguably terrible of this to bundle all its third-party dependencies like it does, and I suppose a more refined version could exclude something like //third_party/... from the list of dependent libraries to include.

With the resulting library somewhere in the workspace, the rest of the framework becomes easy enough to build in a genrule. You could do the whole thing in a genrule if bazel could build while it was building.