Skip to content

[docs] GettingStarted.md: Recommend building the --release variant of --xcode #62156

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 1 commit into from
Nov 18, 2022
Merged

[docs] GettingStarted.md: Recommend building the --release variant of --xcode #62156

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
2 changes: 1 addition & 1 deletion docs/HowToGuides/GettingStarted.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -350,7 +350,7 @@ while retaining the option of building with Ninja on the command line.

Assuming that you have already [built the toolchain via Ninja](#the-actual-build),
several more steps are necessary to set up this environment:
* Generate Xcode projects with `utils/build-script --xcode --swift-darwin-supported-archs "$(uname -m)"`.
* Generate Xcode projects with `utils/build-script --release --swift-darwin-supported-archs "$(uname -m)" --xcode`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn’t release be harder to debug though due to inlining etc.?

Copy link
Collaborator Author

@AnthonyLatsis AnthonyLatsis Nov 17, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--xcode doesn’t build anything anymore, aside from a subset of LLVM that for some reason is required to configure the Xcode projects. The resulting build artifacts are not used for anything else in this workflow, so there’s nothing to run and potentially debug. That is all done via the Ninja build through manually configured targets and schemes. Or am I perhaps misinterpreting your point?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case - great!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that somehow affect indexing of sources? May it has nothing to do with it, but I did had that impression when I tried. Or maybe was just an impression... Did you experienced something like this?

Copy link
Collaborator Author

@AnthonyLatsis AnthonyLatsis Nov 18, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Frankly, I have not tried the release variant yet, this just came to my mind spontaneously. Mine’s a RelWithDebInfoAssert (I used to just borrow the build-script arguments that I pass for Ninja), and the only indexing issue I’ve faced so far is the one described in the tutorial — when you round-trip Xcode through a distant branch with non-trivial differences in the project structure. I am convinced this is an Xcode caching issue though, since you can fix it by deleting the cache. Indexing is based on type-checked ASTs, so the state of the optimization switch shouldn’t matter.

This will first build a few LLVM files that are needed to configure the
projects.
* Create a new Xcode workspace.
Expand Down