Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Configuration doesn't block native -> Skylark rules migration #5578

Closed
gregestren opened this issue Jul 11, 2018 · 2 comments
Closed

Configuration doesn't block native -> Skylark rules migration #5578

gregestren opened this issue Jul 11, 2018 · 2 comments
Assignees
@juliexxia
Labels
P1 I'll work on this now. (Assignee required) team-Configurability platforms, toolchains, cquery, select(), config transitions

Comments

@gregestren
Copy link
Contributor

Part of the Skylark build configuration project.

This is a tracking issue supporting the effort to re-implement all native Bazel rules (i.e. rules defined directly in the Bazel binary) in Skylark. This issue is considered closed when configuration no longer blocks that effort. That specifically means:

  1. All --my_language_some_flag Bazel definition must be expressible in Skylark
  2. All native configuration transitions must be expressible in Skylark

There's not much to do specifically for this issue. This is basically an aggregate of #5574, #5575, and #5577.

This complements the Bazel Configurability Roadmap. Write questions / comments / status updates here. See there for the bigger picture.
@gregestren gregestren added team-Configurability platforms, toolchains, cquery, select(), config transitions P1 I'll work on this now. (Assignee required) and removed category: extensibility > configurability labels Nov 28, 2018
bazel-io pushed a commit that referenced this issue Apr 9, 2019
@juliexxia @copybara-github
Allow starlark transitions to read starlark-defined options.
1a70c27 
Calculate and supply defaults for all read starlark options before transitions are applied. Future work includes:
- combining skyfunction calls for inputs and outputs of starlark transitions
- enforcing that BuildOptions.starlarkOptions will never hold default values (opposite of native options which always hold default values) in order to make BuildConfigurationWithDefault == BuildConfigurationWithNoValue
- Making sure BuildConfiguration properly reflects StarlarkOptions

Work towards #5574, #5577, #5578

RELNOTES: None.
PiperOrigin-RevId: 242681946
@gregestren
Copy link
Contributor Author

April '19 update:

Ongoing challenges are the complicated types of some native flags. It remains a goal to be equally powerful with Starlark-defined flags without inheriting ugliness from, say, carbon copying exactly how native typing works today. Also current work on host / execution transitions requires some thought, since those make changes in native code that needs a corresponding Starlark API.

@dslomov dslomov removed the bazel 1.0 label Sep 2, 2019
@gregestren
Copy link
Contributor Author

Jan '20 update:

While ongoing work remains, the core APIs are implemented and solid. This no longer makes sense as a coherent wide-reaching bug. We should move these themes forward with specific feature requests for specific needs for specific rule classes.

Priorities are now determined by individual rule migration schedules vs. major blockers on any of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@juliexxia juliexxia

Labels
P1 I'll work on this now. (Assignee required) team-Configurability platforms, toolchains, cquery, select(), config transitions
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@laurentlb @dslomov @gregestren @juliexxia