Comments (4)
Chiming in after finding myself doubly redefining a bunch of {OS} x {CPU} combinations as config_setting()s and platform()s in my own projects...and seeing others do the same.
It definitely seems to me like it'd be great to have the common combinations officially in @platforms rather than having everyone (Bazel included) roll their own. Could be either the full cartesian product (yay list comprehensions!) or the subset that exist in the wild as physical machines. (Doubt the unused ones would hurt people, though.)
Some side notes:
- It's pretty sweet to be able to select on constraint_value()s, eliminating this problem for single values. Thank you for that!
- I've read the reasoning behind not letting people select on platforms (i.e. encouraging people to not write too narrow of selects()s...) but I would really like to put in a pitch for reversing in the context of the this issue. It seems like an avoidable bummer to duplicately define them and then have people be confused about which to use--especially if they're defined in an official place.)
Edit: Additional discussion on this emerged over in bazelbuild/bazel#14604 (comment)
Thanks so much for your consideration!
Chris
(ex-Googler)
from platforms.
I would start with the assumption that we want to eliminate/reduce the surface of @bazel_tools//src/conditions. If Bazel needs those conditions to build itself, then it can import them from a package, or declare them in its own BUILD files. To put it in a different light, the set or platforms we need for building Bazel is a completely distinct thing from the set of platforms that people build for.
But then does it serve everyone best to move them here? It seems to me that the android platforms should come with the android toolchains, and the apple ones with rules_apple.
from platforms.
@aiuto, to try to answer the above (slowly, sorry): I do still think so.
As a concrete motivating example: cc_libraries (like boost, for example) need to use them to select on, e.g, backends, but don't/shouldn't otherwise require rules_apple. (Boost is one of the several places I've reimplemented this, I think, and what prompted the comment above and our parallel discussion in #37.) This is the same reasoning, I'd think, that, e.g., @platforms//os:macos lives here rather than rules_apple. More generally, isn't the general philosophy to try to have general, universally selectable platforms logic live here?
That is, offhand, I'd favor having knowledge about which platforms exist centralized here, for all the same good reasons it is already, with knowledge about how to build for them being federated.
from platforms.
FWIW, seeing this duplicated again, contributing to boringssl. Still think the cross product would be valuable here--entirely parallel reasons to boost; these cross platform native libraries don't (and shouldn't) pull in rules_apple, android, etc. That is, it seems to me like the best acyclic dependency graph for reusability would be to put them here and reuse those defs for Bazel, boost, boringssl, apple, android, etc.
from platforms.
Related Issues (20)
- [discussion] Decide whether or not to express FPU nuances for `@platforms//cpu:armv*-m*` constraints HOT 4
- Add presubmit tests to validate platform definitions HOT 1
- Add cpp examples HOT 1
- Platform Commonalities: e.g. Apple, POSIX, etc. HOT 20
- Constraints for ABI HOT 22
- Define a value for "no OS"? HOT 3
- platforms 0.0.6 not published to central registry HOT 1
- How to reference the platform repository. HOT 2
- MacOS being detected as multiple OSes HOT 13
- Repository `@rules_license` is not defined HOT 4
- Prefer cpu:aarch64 to cpu:arm64
- Implement Standard Platform Transitions HOT 2
- Issue specifying linux platform constraint to bazel workspace HOT 3
- platform_data syntax error
- i386 vs x86_32 HOT 1
- When will the next version be released to the Bazel Central Register? HOT 1
- [question] bazel platforms for c/c++ how to distinguish the toolchain while they are same cpu and os
- `//cpu:ppc64` HOT 1
- Support for UEFI targets
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from platforms.