| Age | Commit message (Collapse) | Author |
|---|
|
simpleperf-release
Change-Id: Icda792b8881c38405026139b2ac1feda85356552
|
|
This project was upgraded with external_updater.
Usage: tools/external_updater/updater.sh update bazelbuild-platforms
For more info, check https://cs.android.com/android/platform/superproject/+/main:tools/external_updater/README.md
Test: TreeHugger
Change-Id: I0345a4b753847338ec01f0c8a427fe0d976b2211
|
|
Change-Id: Ia21454f8f7a2e6f26f4d3503dc0f727510e8a779
|
|
Change-Id: Iba607b81ac89c1902a84ed5fab867a9e3e8a1712
|
|
* add bzlmod stuff to dist
* get ready for version 0.0.8
* fix typo in license dep
|
|
This is a specific cpu variant of ppc64 in little-endian mode.
GOARCH has equivalent: https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63#goarch-values
Debian also builds (though with weird naming): https://wiki.debian.org/ppc64el
It is weird that the other entries here are ppc and ppc32, I would actually expect ppc and ppc64 but :shrug:
|
|
Co-authored-by: aiuto <aiuto@google.com>
|
|
Co-authored-by: aiuto <aiuto@google.com>
|
|
* 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>
|
|
Update rules_license deps to current.
|
|
|
|
Add Apple visionos.
|
|
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?
|
|
Add :aarch32 :aarch64 and make :arm64 alias for :aarch64
|
|
"aarch64" is the perferred name and used prevailingly on Linux.
See https://nickdesaulniers.github.io/blog/2023/03/10/disambiguating-arm/
Apple and Windows platforms unfortunately use "arm64". They can still
use the alias.
While here, add :aarch32 as well.
Close #68
|
|
Replace bazel-dev with GitHub Discussions.
|
|
Co-authored-by: Yun Peng <pcloudy@google.com>
|
|
|
|
|
|
Add rules_license style declaration.
|
|
|
|
|
|
- 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.
|
|
Add cortex-r52 r82 cpus
|
|
|
|
|
|
|
|
Add Cortex-R52, PPC32 cpus
|
|
|
|
|
|
|
|
Add MODULE.bzl
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Improve the helper script to make a platforms release
|
|
|
|
Add chromiumos
|
|
|
|
|
|
|
|
Add //os:haiku constraint
|
