rules_xcodeproj: Bug: Failing to build "hello world" using the generated xcodeproj

What happened?

After opening the xcode project for a test repo and hitting Cmd+b to build the project, the build fails instantly with the following:

Showing All Messages
unexpected service error: build aborted due to an internal error: unable to write manifest to '/Users/photex/workspaces/avid/bazel-example/build/XCBuildData/53d14b36fb80c1f9954735757badae12-manifest.xcbuild': File exists but is not a directory: /Users/photex/workspaces/avid/bazel-example/build

This would appear to be a problem with a case-insensitive file system right? The path /Users/photex/workspaces/avid/bazel-example/build points to the BUILD file in the root of my repo.

Reproduction steps

Just create a hello world cc_binary, and generate an xcodeproj using the instructions on the readme.

My system is Ventura, Xcode 14.2.

Expected behavior

I expect that the generated Xcode project would build and debug the executable that otherwise builds and runs fine with Bazel and CLion.

rules_xcodeproj version

1.3.3

Bazel version

6.1.1

rules_apple version

No response

rules_swift version

No response

Additional information

No response

About this issue

Original URL
State: closed
Created a year ago
Comments: 22 (8 by maintainers)

Most upvoted comments

Hi everyone!

Thanks for sticking around and I appreciate your patience. I can confirm that the issue was the “Locations” settings. At work our setup expects the “Legacy” setting (we are only recently working on the transition to Xcode 14 and have been leaning on the legacy build system for far too long in my opinion).

I changed this to one of the other options and was able to work with the generated Xcode project after that!

Thanks for all the help!

photex on Apr 17, 2023

Also be sure to check your Xcode “Locations” settings. If you set Xcode to have Derived Data to be “Relative”, it will by default build to a build directory, which can clash with any BUILD files. If you need to do that, make sure you rename your root BUILD file to BUILD.bazel. You probably will need to add the build folder to .bazelignore as well.

brentleyjones on Apr 12, 2023

Thanks for sticking with me here folks. 😄 I’ll give everything a try and follow up after I’m done with work.

photex on Mar 30, 2023

it fails initially because of the case-insensitive filesystem and a BUILD file in the root.

I don’t think this makes sense to me. macOS is by default case-insensitive, and we have never seen the examples fail in this way.

I’m on macOS Ventura and the examples work for me on a default macOS file-system.

Now that I look back at the screenshot in https://github.com/MobileNativeFoundation/rules_xcodeproj/issues/1924#issuecomment-1490046999, I see that there’s a log in the “Bazel Dependencies” step that prints this message: https://github.com/MobileNativeFoundation/rules_xcodeproj/blob/9a2fd8ca9d7dc1d86fc8ec116b84f70282d97216/xcodeproj/internal/bazel_integration_files/generate_bazel_dependencies.sh#L74-L75

It looks like it’s not even building anything at all, that’s why the copying is failing to find the outputs. I would try to add some echo statements in those scripts (they can be found in BazelExample.xcodeproj/rules_xcodeproj/bazel) and see exactly why the output group isn’t set.

BalestraPatrick on Mar 30, 2023

and then change the suffix execroot/_main to rules_xcodeproj/build_output_base/execroot/_main and see if this directory indeed exists

Btw, you can use the command-line API to get this in one command:

$ bazel run //tools/generator:xcodeproj -- 'info execution_root' 2>/dev/null
/Users/brentley/Developer/rules_xcodeproj/bazel-output-base/rules_xcodeproj/build_output_base/execroot/_main

brentleyjones on Mar 30, 2023