Skip to content

docs: add question about rules_xcodeproj and spawn strategy #713

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Nov 1, 2023
Merged

docs: add question about rules_xcodeproj and spawn strategy #713

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9600826
doc: add question about rules_xcodeproj and spawn strategy
cgrindel Nov 1, 2023
b52ce73
Add missing link
cgrindel Nov 1, 2023
b2c99d6
Ran tidy
cgrindel Nov 1, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 21 additions & 4 deletions docs/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,7 @@
* [After running `//:swift_update_pkgs`, I see a `.build` directory. What is it? Do I need it?](#after-running-swift_update_pkgs-i-see-a-build-directory-what-is-it-do-i-need-it)
* [Does the Gazelle plugin run Swift package manager with every execution?](#does-the-gazelle-plugin-run-swift-package-manager-with-every-execution)
* [Can I store the Swift dependency files in a sub-package (i.e., not in the root of the workspace)?](#can-i-store-the-swift-dependency-files-in-a-sub-package-ie-not-in-the-root-of-the-workspace)
* [My project builds successfully with `bazel build ...`, but it does not build when using `rules_xcodeproj`. How can I fix this?](#my-project-builds-successfully-with-bazel-build--but-it-does-not-build-when-using-rules_xcodeproj-how-can-i-fix-this)
<!-- MARKDOWN TOC: END -->

## Why use Gazelle and Go?
Expand All @@ -25,15 +26,15 @@ plugins for other languages](https://github.com/bazelbuild/bazel-gazelle#support
Letting Gazelle generate and maintain Bazel build files is a real game changer for developer
productivity.

## Why split the implementation between Go and Starlark?
## Why split the implementation between Go and Starlark?

As mentioned previously, the easiest way to implement a Gazelle plugin is to write it in Go. This
works great for generating build files in the primary workspace. However, there is a chicken-and-egg
problem when it comes time to generate build files in a repository rule. The repository rule needs
to generate files during the [loading phase]. The Go toolchain and the Gazelle framework defined in
the workspace are not available to the repository rule during this phase. So, one needs to either
perform some gymnastics to build the Gazelle plugin (see below) or use a language/runtime that is
guaranteed to be available during the loading phase. Since Starlark is available during the loading
guaranteed to be available during the loading phase. Since Starlark is available during the loading
phase, the build file generation logic for the repository rules is implemented in Starlark.

### How does the Gazelle plugin for Go handle this?
Expand Down Expand Up @@ -72,7 +73,7 @@ Yes. Just omit the `//:update_build_files` target that is mentioned in the [quic

The `//:swift_update_pkgs` target runs the Gazelle plugin in `update-repos` mode. This mode
resolves the external dependencies listed in your `Package.swift` by running Swift package manager
commands. These commands result in a `.build` directory being created. The directory is a side
commands. These commands result in a `.build` directory being created. The directory is a side
effect of running the Swift package manager commands. It can be ignored and should not be checked
into source control. It is not used by the Gazelle plugin or the Starlark repository rules.

Expand All @@ -89,8 +90,24 @@ the source files that exist in your project to generate the Bazel build files.
Yes. The [vapor example] demonstrates storing the Swift dependency files in a sub-package called
`swift`.

## My project builds successfully with `bazel build ...`, but it does not build when using `rules_xcodeproj`. How can I fix this?

[loading phase]: https://bazel.build/run/build#loading
tl;dr Add the following to your `.bazelrc`.

```
# Ensure that sandboxed is added to the spawn strategy list when building with
# rules_xcodeproj.
build:rules_xcodeproj --spawn_strategy=sandboxed,remote,worker,local
```

This can happen with some Swift packages (e.g. `firebase-ios-sdk`). [rules_xcodeproj removes the
`sandboxed` spawn
strategy](https://github.com/MobileNativeFoundation/rules_xcodeproj/blob/6c186331c82f3cbc82e2e7fdfacb4873e409e094/xcodeproj/internal/templates/xcodeproj.bazelrc#L66-L68)
in their default build configuration due to slow performance of the MacOS sandbox. The above bazelrc
stanza adds it back. [An issue](https://github.com/cgrindel/rules_swift_package_manager/issues/712)
exists tracking the work to allow these Swift packages to be built using the `local` spawn strategy.

[loading phase]: https://bazel.build/run/build#loading
[quickstart]: https://github.com/cgrindel/rules_swift_package_manager/blob/main/README.md#quickstart
[rules_spm]: https://github.com/cgrindel/rules_spm/
[rules_swift]: https://github.com/bazelbuild/rules_swift
Expand Down