* POC: implement local_config_platform in @platforms
* missing colons
* move stuff around
* the repo rule need not be public
* attempt at a test setup...
* whoops
* newlines
* comments
* more comments
* Bazel Platforms: Add `//cpu:any` constraint value for arch-indep builds
Some builds are expected to only produce architecture-independent data files,
such as configuration files, database seed data, composited images, or even
some kinds of interpreted scripts (Shell, Python, Perl, etc).
When such a build is being performed, this constraint value may be used to
ensure that architecture-dependent builds cannot be performed (except by way
of another transition).
As a final example, consider building a package of NIC firmware images for
many different NIC models. The package overall is architecture-independent,
and should be built with `//cpu:any`, then each individual image rule has a
transition to the suitable architecture for that specific NIC model.
* Update BUILD
Changed "any" to "all"
* Update BUILD
Fix comment
---------
Co-authored-by: aiuto <aiuto@google.com>
I'm not really satisified with this PR. The number of Apple specific platforms has grown to the point where we may want to refactor them. The question I would focus on is how various toolchain matches and select clauses go.
Do we see things like:
```
foo = select({
".../os:linux": A,
".../os:windows": B,
".../os:macos": C,
".../os:watchos": C,
".../os:visionos": C,
})
```
Where C is the same for all the apple platforms?
Or, do we see real distinctions across the various per-device OSes. Or a mix of both?
And, do we see the fanout of the Apple OSes done with a select_or wrapper, so users end up seeing the simple selection of just apple, linux, or windows, but we buried complexity elsewhere?
- That picks up version that users cfg=exec instead of cfg=host
- It still works with bazel 5.x. The next rules_license might not.
- bump our version to 0.0.7 for next release
- add presubmit check that we did not mistmatch the license
- Done for both WORKSPACE and bzlmod styles
- The dependency is different because rules_license is not
up to date in the BCR. I'll correct that at the next
rules_license release.
