featherless 26b5e48574
[bazel] Implement Swift import rewriting as part of Bazel. (#9368)
Context
-------

Prior to this PR we were unable to build our Swift source code as part of the Bazel toolchain because our source supports CocoaPods-style framework imports out of the box. E.g.:

```swift
import MaterialComponents.MaterialAppBar
```

Supporting CocoaPods imports enables us to use a pure open source workflow with our code that ensures we're using and validating the latest community technologies (including CocoaPods and native Xcode build systems). Changing our source to Bazel-first was explored as an option for this PR, but was rejected in service to maintaining our CocoaPods support.

The way we solved this import problem before this PR was to perform a global rewrite of import statements prior to invoking any `bazel` commands. This rewrite phase happened as part of the `.kokoro` script. This meant that the only way to run `bazel` commands on our repo was through the `.kokoro` bootstrap script.

This change does not yet entirely remove our need for the `.kokoro` bootstrap script, but it does remove the need for it to rewrite Swift imports. This change is one part of #5491.

The change
----------

This change introduces a new drop-in replacement for swift_library called `_mdc_cocoapods_compatible_swift_library` (for private use within the `material_components_ios.bzl` file) and `mdc_swift_library` for use in all BUILD files. `_mdc_cocoapods_compatible_swift_library` is made use of by several `mdc_` rules, including the new `mdc_swift_library` rule which should now be used instead of `swift_library` throughout our repo.

The new rule's implementation is documented in the source.

The impact
----------

Prior to this change, running the following command:

```
bazel build //components/Typography:SwiftExamples
```

Would result in the following error:

```
components/Typography/examples/TypographyFontListExample.swift:15:8: error: no such module 'MaterialComponents.MaterialTypography'
import MaterialComponents.MaterialTypography
```

After this change, running that same command will give the following successful result:

```
INFO: Invocation ID: 324c8887-d733-42ce-be06-20d9823bf718
INFO: Build options have changed, discarding analysis cache.
INFO: Analysed target //components/Typography:SwiftExamples (3 packages loaded, 365 targets configured).
INFO: Found 1 target...
Target //components/Typography:SwiftExamples up-to-date:
  bazel-bin/components/Typography/libSwiftExamples.a
  bazel-bin/components/Typography/components_Typography_SwiftExamples.swiftdoc
  bazel-bin/components/Typography/components_Typography_SwiftExamples.swiftmodule
INFO: Elapsed time: 4.299s, Critical Path: 4.01s
INFO: 2 processes: 2 darwin-sandbox.
INFO: Build completed successfully, 3 total actions
```

Note that as a result of this change, build output for the transformed src will point to the generated source files rather than the original source files. E.g.:

```
ERROR: /Users/featherless/workbench/material-components-ios/components/Typography/BUILD:55:1: SwiftCompile components/Typography/components_Typography_SwiftExamples.swiftmodule failed (Exit 1) bazel_xcode_wrapper failed: error executing command bazel-out/host/bin/external/build_bazel_rules_swift/tools/wrappers/bazel_xcode_wrapper bazel-out/host/bin/external/build_bazel_rules_swift/tools/wrappers/swift_wrapper /usr/bin/xcrun swiftc ... (remaining 3 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
bazel-out/darwin-fastbuild/genfiles/components/Typography/examples/TypographyFontListExample.bazel_imports.swift:20:1: error: expressions are not allowed at the top level
typo
^
bazel-out/darwin-fastbuild/genfiles/components/Typography/examples/TypographyFontListExample.bazel_imports.swift:20:1: error: use of unresolved identifier 'typo'
typo
^~~~
```

This is the downside to this change, but it only materially impacts eng workflows if we start using Bazel to generate Xcode projects. As command line output, it's fairly straightforward to transform the path to the correct original source path. If we do someday move to a Bazel-generated Xcode project workflow, then we should also revisit our assumption that our source should support CocoaPods out of the box. As noted at the beginning of this PR, however, this consideration is deemed out of scope for this PR.
2020-01-02 12:18:38 -05:00
..

Scripts

Scripts for maintaining Material Components for iOS—none of these scripts are required to use MDC or for casual contributors.

The important scripts are:

  • prep_all: prepare the Material Components catalog, tests, and demos apps for building.
  • build_all: build the Material Components catalog and each of our demo apps.
  • test_all: build and test the Material Components unit and integration tests.
  • clean_all: remove artifacts from the prep_all, build_all, and test_all scripts.
  • check_components: run component checks for documentation, examples, etc.
  • install_contributor_tools: install local contributor tools to speed up the development cycle.

Languages

Material Components follows Google's language standards for scripting. The following languages can be used for scripts:

Either language can be used for a particular purpose, but larger or more complex scripts should be written in (or converted to) Python. Bash scripts get unwieldy quickly and advanced Bash scripting knowledge is currently less common than advanced Python scripting knowledge.

The intent is that the scripts will run on relatively current OS X machines with (only) Xcode installed.

iOS Codelabs Build Tests

iOS codelabs build tests ensure that the Objective C and Swift versions of Codelab 104 Complete and Codelab 111 Complete can be built. If a release fails the codelabs build tests, follow these steps:

  1. If the release changes a component that the codelabs use, submit a PR to the codelabs repo with the appropriate changes for the adjusted component. Address each codelab and language that is affected by the change (it may be helpful to run ./build_codelabs -a to determine which codelabs are affected).
  2. Merge the PR into the codelabs repo, and then rerun the codelabs build tests.
  3. Continue with the release process.