This repository has been archived by the owner on Mar 4, 2024. It is now read-only.
Sync upstream #75
Merged
Sync upstream #75
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
External BuildLabels were keeping their // halfway through their path, leading to projects xcode would refuse to load. As an example: @google_toolbox_for_mac//Foundation:BUILD was going to external//Foundation/BUILD, not external/Foundation/BUILD. This lead the pbjproj to assign the file the path //Foundation/BUILD, which Xcode refuses to load, along with groups named '/' and the omission of other associated source files.
…le Execroot (#255) * Fix breaking of external workspaces after builds Previously, paths to files in external workspaces went through execroot. Execroot is reconfigured on every rebuild to contain only the external workspaces (and top-level packages) required by that build. Therefore, executing a build that used a subset of the project's external workspaces broke the file references and include paths for the other external workspaces. Bad times. This commit points to external workspaces through the stable external subdirectory of output_base instead of the unstable external subdir of execroot. This requires a new tulsi symlink for output base; Xcode doesn't properly resolve ../ paths through symlinks for file references. Plus, we should probably try to move away from linking through a temporary build sandbox anyway; it'll just keep leading to subtle bugs. This should close bazelbuild/tulsi#164 This patches bazelbuild/tulsi#227 and bazelbuild/tulsi#229. This commit also contains a fix for an (I think unreported) bug I noticed while editing ProjectPatcher. In trying to fix paths for files not on disk, it was unintentionally setting their paths to (an incorrect) path that was group relative, but meant to be project relative. It also created inconsistent state in the PBGroup hierarchy. Since this fixes the paths for generated Info.plists in most projects, it leads to many of the file ref path changes in the tests. The code now does what the author clearly intended, and I've added some defence against future issues into PBXObjects. * Make execroot symlink's names reflect what it is tulsi-workspace -> tulsi-execution-root TULSI_BWRS -> TULSI_EXECUTION_ROOT * Re-add legacy names for execroot build setting and symlink for backwards compatibility Fixes bazelbuild/tulsi#164.
…i's E2E tests. PiperOrigin-RevId: 367058875 (cherry picked from commit debe5ac)
…plicit module maps. LLDB will transitively include an option that disables implicit module maps when importing a Swift module that depends on an Objective-C library that was built with explicit modules. Depending on the build graph, this can mean LLDB's clang module importer can fail to find the required module maps and provide no debug info. PiperOrigin-RevId: 371927956 (cherry picked from commit dbb0fc4)
PiperOrigin-RevId: 372147605 (cherry picked from commit 5ef399c)
PiperOrigin-RevId: 373199701 (cherry picked from commit 9939243)
PiperOrigin-RevId: 374475916 (cherry picked from commit ee965f2)
PiperOrigin-RevId: 374489201 (cherry picked from commit 21cc1c8)
…he of any modules that are found in a metadata file that is intended to be created by a bazel aspect that collects explicit module build outputs. This tool is needed to avoid a crash with LLDB that occurs when the LLDB module cache contains a module that is also generated in a build as an explicit module. This chnage handles reading metadata files that a bazel aspect will write to come up with a list of names of all explicit modules that will have been created from a build. PiperOrigin-RevId: 378248354 (cherry picked from commit 078e311)
…he of any modules that are found in a metadata file that is intended to be created by a bazel aspect that collects explicit module build outputs. This tool is needed to avoid a crash with LLDB that occurs when the LLDB module cache contains a module that is also generated in a build as an explicit module. This change handles reading the contents of the implicit module cache and map the name of each module to the absolute path of that module. PiperOrigin-RevId: 378402314 (cherry picked from commit a03f6ef)
…he of any modules that are found in a metadata file that is intended to be created by a bazel aspect that collects explicit module build outputs. This tool is needed to avoid a crash with LLDB that occurs when the LLDB module cache contains a module that is also generated in a build as an explicit module. To summarize how this works: - Read the contents of the implicit module cache and map the name of each module to the absolute path of that module. - Read metadata files that a bazel aspect will write to come up with a list of names of all explicit modules created from a build. - Iterate through the list of explicit module names and delete any module with the same name from the implicit module cache. - Compute a hash of the list of explicit module names that were used to prune the implicit module cache. - Save that hash to a special sentinel file in the implicit module cache. - Compare the hash of subsequent builds to the one in the file to determine if subsequent builds should prune the implicit module cache. PiperOrigin-RevId: 378666180 (cherry picked from commit 55b6a92)
Disable this as it can annoy users; we're working on new build system support. PiperOrigin-RevId: 378916679 (cherry picked from commit 3f25dd7)
…ests. Tulsi doesn't allow list ios_static_framework rules, so the e2e test appears to ignore this target. PiperOrigin-RevId: 378933587 (cherry picked from commit 31da848)
…f Unstable Execroot (#255)" This reverts commit c7609aa.
…ule in the build graph to use Swift explicit modules. - Updates the Tulsi outputs aspect to output the Swift explicit modules generated from a build. - Bundles the module cache pruning tool with the Tulsi app bundle and installs it to the same location as the bazel_cache_reader. - Runs the module cache pruning tool after each Tulsi build, providing the output from the aspect, to prevent lldb from loading the outdated implicit module. PiperOrigin-RevId: 378936605 (cherry picked from commit 98d6f25)
Significant changes: - Fixed a crash with lldb-rpc-server that can occur after migrating a rule to use Swift explicit modules. PiperOrigin-RevId: 379284179 (cherry picked from commit e4fcc3c)
…eeding to explicitly drop the return value when not using it. PiperOrigin-RevId: 382075141 (cherry picked from commit 552b356)
This allows us to remove the special internal entitlements rule and convert nearly all of the existing macro-wrapped rules into pure rules, with the exception of some macOS rules which still have some straggling items to migrate. PiperOrigin-RevId: 382347912 (cherry picked from commit 286d21b)
…isabled by default. bazel_cache_reader has been observed to result in significant hits to symbolication in some cases. PiperOrigin-RevId: 382537207 (cherry picked from commit 6fe2926)
PiperOrigin-RevId: 382571317 (cherry picked from commit d3e3536)
Significant changes: - Unsupported tests in test_suites are now skipped instead of throwing an error. - Disable fallback dSYM searching by default. The fallback can be reenabled with the "Enable fallback dSYM searches" option. Reenabling is only recommended if Spotlight is disabled as it can impact time to symbolicate a binary. - Fixed a crash with lldb-rpc-server that can occur after migrating a rule to use Swift explicit modules. PiperOrigin-RevId: 384527057 (cherry picked from commit 7440ba0)
PiperOrigin-RevId: 386871254 (cherry picked from commit febfc91)
Show the entire diff at once instead of line-by-line PiperOrigin-RevId: 389889488 (cherry picked from commit d16d184)
``` buildfiles(deps($T1)+deps($T2)+deps($T3)+[...]) ``` is equivalent to, but generally much slower than ``` buildfiles(deps($T1+$T2+$T3+[...])) ``` PiperOrigin-RevId: 389912462 (cherry picked from commit a5ef86e)
Also fix an issue with the OSS tests. PiperOrigin-RevId: 390164332 (cherry picked from commit d1a4d3c) # Conflicts: # .bazelci/presubmit.yml # .bazelrc # WORKSPACE
Significant changes: - Improved performance when querying for BUILD/bzl files PiperOrigin-RevId: 391546363 (cherry picked from commit 53d31b0)
- Use the newer `--run_validations` flag - Disable the `dsyms` output group that some folks might manually enable by accident PiperOrigin-RevId: 393791135 (cherry picked from commit 043040df1bc175b5f71d7af80877af0fa98e28f1)
PiperOrigin-RevId: 396918740 (cherry picked from commit f151befb3900ae1f122fdf5a4dc2b0870dffd95c)
Updated to be in sync with our current Xcode target of Xcode 12.5.1 PiperOrigin-RevId: 399783838 (cherry picked from commit a3dec4cc165ca4044215f523bac06b1bf7623861)
Only warnings left now are hashValue, which are a bit more complicated to fix due to our usage in PBXObjectProtocol. PiperOrigin-RevId: 426146113 (cherry picked from commit 0ea4f83afa7f378294c642e9c7994d5ce33335e0)
Significant changes: - Extra build flags can now be specified during project generation via `--build-options`, e.g. `--build-options "--keep_going --verbose_failures"` - Fix a warning about root-level library targets that was being printed under incorrect conditions. PiperOrigin-RevId: 427737504 (cherry picked from commit d4d0e2cd7a8f3ecff3a8efda0fb43c4f470564d5)
Since Tulsi appends this flag to the build command, `--output_groups=tulsi_outputs,default` would override any previously defined `--output_groups` flag. From the [documentation](https://bazel.build/reference/command-line-reference#flag--output_groups): `--output_groups=+foo,+bar` builds the union of the `default` set, `foo`, and `bar`, while `--output_groups=foo,bar` overrides the default set such that only `foo` and `bar` are built.
To work around the drop of `should_lipo` in `apple_common.link_multi_arch_binary`.
Currently this will only be used if the `UseLegacyBuildSystem` option is false. PiperOrigin-RevId: 428076981 (cherry picked from commit 0fb177476c76043167546a9a7b3aae692738e1b0)
Workaround to make it builds with Xcode 13.3.
The current timeout is not long enough to run on GitHub Actions.
This is helpful so folks can know who the POC can be for their issues and PRs
Now that the swift worker uses json instead of protobuf this is no longer a concern
There's a change in Bazel rolling that is required for this: https://github.com/bazelbuild/bazel/blob/4858cbfa37d5ed96fb282280819a3577064eb51d/src/main/java/com/google/devtools/build/lib/rules/config/ConfigGlobalLibrary.java#L123-L126 Otherwise the build would fail with: ``` Error in transition: Invalid transition input '//command_line_option:incompatible_enable_apple_toolchain_resolution'. Cannot transition on --experimental_* or --incompatible_* options ```
Since the new build system will always inject the test artifacts after our run script phase for UI tests, we instead add a new PBXAggregateTarget which allows us to run another script after the initial UI test target (including the runner) is built. In addition, we no longer attach xcdatamodels to indexer targets since it can trigger issues in the new build system. Xcode has issues inferring their paths and can accidentally scan the workspace root instead of the xcdatamodeld dir. PiperOrigin-RevId: 428078393 (cherry picked from commit 65607ed821c4d540cc9f75563e2f06392bebc8e3)
This is currently unused. PiperOrigin-RevId: 429136722 (cherry picked from commit c8927202d75c2811de97b7eaa7238bdf3d0c7d3a)
This is currently not used. PiperOrigin-RevId: 430227601 (cherry picked from commit f1104d368fb47fcdfbeb2e0d89c4b960920219a1)
Significant changes: - Added a mechanism to create announcement messages in Tulsi CLI output - Added a dismissible announcement mechanism. PiperOrigin-RevId: 433782888 (cherry picked from commit 023e5751f849ea5d3a7d69117e35106b90b84734)
…proj.sh build_and_run.sh now install to $HOME/Applications by default. Change the default Tulsi location in generate_xcodeproj.sh to sync with this.
This ensures framework search paths are collected properly for indexing targets.
This is required after the following change: bazelbuild/rules_swift@d39d966
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
sync to bazelbuild/tulsi@b4c82ea