| commit | d9b141def7aa7737dc09d5c490222c101630df77 | [log] [tgz] |
|---|---|---|
| author | mstaib <mstaib@google.com> | Thu Sep 14 20:47:31 2017 +0200 |
| committer | Philipp Wollermann <philwo@google.com> | Fri Sep 15 11:28:15 2017 +0200 |
| tree | 898faa9945a766ffc8534c8a4fbcd1c25aecb91f | |
| parent | dc4dddf7bd2b9963c4d181de75c0809657fb5d4b [diff] |
Use top-level targets' configurations for convenience symlinks. This adds a new flag, --use_top_level_targets_for_symlinks. Configuration-specific convenience symlinks (i.e., (prefix)bin, (prefix)genfiles, (prefix)testlogs) previously pointed at the one top-level target configuration. If there were multiple top-level target configurations, which could only happen when --experimental_multi_cpu was used, then no symlinks would be created, though they would not be deleted either. With the flag on, the output directories of the configurations actually used by the top-level targets (after rule class transitions etc.) are compared. If all targets with non-null configurations have the same configuration (or, more specifically, if all targets with non-null configurations have configurations with the same output directory), then a symlink is created pointing at it. Otherwise, the symlink is deleted, to avoid confusion with stale symlinks from old builds. Known changes in behavior WITHOUT the flag turned on: * In the --experimental_multi_cpu case, non-configuration-specific convenience symlinks (i.e., (prefix)(workspace) and (prefix)out) will always be created, even though they previously wouldn't have been created at all in this case. (should be harmless) * In the --experimental_multi_cpu case, configuration-specific convenience symlinks will be created if all configs have the same output directory. (should be safe, or specifically, should never happen because multi-cpu would necessarily change the output path, but shouldn't hurt anything even if it did) * In the --experimental_multi_cpu case, configuration-based convenience symlinks will be deleted if some configs have a different output directory. (slightly more noticeable since that will be every build using experimental_multi_cpu, but then, it is experimental) RELNOTES: None. PiperOrigin-RevId: 168720843
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel only rebuilds what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase and Continuous Integration system. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
See CONTRIBUTING.md
Bazel is released in ‘Beta’. See the product roadmap to learn about the path toward a stable 1.0 release.