Support cc_binary

[adamhowardprice]

We tried to use Tulsi to generate an Xcode project for a C++ library to be built with Bazel, and it failed, with the error message “Unsupported target: cc_binary”. I hope this will be supported in the future.

[jgavris]

👍

[adamhowardprice]

@kelvinchan-google Is this on the roadmap?

[kelvinchan-google]

Thanks for the feature request. Unfortunately at this point, this isn't on the roadmap for 2017 due to the limited bandwidth of the Tulsi team.

[steren]

@adamhowardprice is the request about being about to edit the C++ code of this binary in XCode?
Or is the cc_binary a transitive dependency of your ios_application that you just want to use for building?

[jgavris]

I don't speak for Adam, but source-level navigation / debugging would be fantastic. Especially with fast builds thanks to bazel.

[steren]

Thanks. Is the following correct?

• critical (adoption blocker): build an ios_application that depends on a cc_binary.
• nice to have: navigate / debug the C++ code in XCode

[adamhowardprice]

IMO they are both blockers

[adamhowardprice]

We have C++ devs who currently work actively on our Core libraries in Xcode. They would need a way to keep doing this while building with Bazel.

[adamhowardprice]

Also, to clarify, the critical adoption blocker above is having an ios_application that depends on cc_library, not binary.

I think the error we were hitting above was coming up simply because we had a cc_binary rule defined in our project somewhere, and Tulsi was parsing it.

[benvanik]

Would love to see support of cc_library/cc_binary/cc_test (on darwin). Our project includes a mix of types (an ios_application, ios_tests, and cc_tests that run on darwin) and right now we can't debug/edit/index/etc our cc_tests.

[c-parsons]

As a workaround, try using either macos_application under https://github.com/bazelbuild/rules_apple, or, if you want a binary-without-bundle, try apple_binary with the 'macos' platformtype.

[jgavris]

Given that Xcode 9 has new awesome refactoring support, any chance to get cc_* bumped on the roadmap?

[siddharthab]

+1, would really love to have cc_library and cc_binary support for non-Apple applications as well, just to have XCode be usable as an IDE with Bazel rules.

[jgavris]

That, or someone can show me how to get the CLion bazel plugin working. But I would prefer Xcode 9.

[siddharthab]

See bazelbuild/intellij#109 for some comments on getting CLion bazel plugin working on Mac. The simplest way is to use a custom toolchain with the crosstool_top build flag.

[dmaclach]

So with c57a1c9 you should be able to use cc_binary/cc_library. Can folks give it a shot and see how it works for them?

[siddharthab]

I am able to select the targets now, but at the "Generating build targets" stage, I get this error: Unsupported target type: cc_binary

The process succeeds if my target is cc_library.

[siddharthab]

Sorry my bad, I was on the wrong branch in git. The project generates fine with this change.

I don't know if other people will agree with this or not, but I found that the Tool type worked better for me, i.e. RuleEntry.swift:131 should be "cc_binary": PBXTarget.ProductType.Tool,

With the Application type, on trying to run my binary, I was getting an error that said that the [target name] could not be opened because I do not have permissions.

I also changed the base SDK in the generated Xcode project to be macOS.

Simple projects build fine, but complex projects have more issues. For example, the include attribute in cc_library rule does not seem to be respected so Xcode parser can not find the header files.

Also, no symbol information in debug mode. I don't know how important people consider this to be.

Thank you for looking into it and making it possible. 👍

[benvanik]

Agreed with siddharthab: cc_binary needs to be marked as PBXTarget.ProductType.Tool; otherwise, Xcode will fail to build because it tries to treat the built binary as a .app bundle directory instead of the file it is.

Symbol information in debug mode is really needed, too - probably related to this: bazelbuild/bazel#2537

[DavidGoldman]

Closing this due to the relevant changes in c57a1c9.

If you're still seeing issues due to PBXTarget.ProductType.Application being used instead of PBXTarget.ProductType.Tool or something else, please open a new issue with further details (an example project would be very useful).