Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Description of the feature request:
Say I have two macros,
The following should also be legal:
Feature requests: what underlying problem are you trying to solve with this feature?
Currently, the latter example above fails with an error message:
This seems like an arbitrary limitation to me. While I understand that
Consider the following example. We have a macro
Currently, the user cannot say e.g.
This is an unnecessary pessimization. It should be legal to define a macro that computes the
What's the output of
There is no distinction between "WORKSPACE macros" and "BUILD macros". The distinction is that some functions, like select, cannot be used in the WORKSPACE file.
select depends on having a configuration to examine and make choices between. When the WORKSPACE is evaluated, there is no configuration present yet, and so select cannot be used.
You need to move the functionality into a BUILD file to use select there, and then have the WORKSPACE register the toolchain that declares the select.
I get that. But my use case detailed above does not need a configuration. The user is providing a
As far as I can tell,
To summarize, I have a public
Can you provide a larger example of what you want to do? I'm afraid I didn't actually understand your use-case.
In the snippet you provided:
There is no way for the macro to expand to change the actual build file. You could conceivably pass a string to the
If users need this level of customization to the
That's exactly what I would like to be able to do, yes.
I'm not sure why. Could you clarify?
They would need to define the tolochain in a separate repository so that
This is why I propose to liberalize the rules regarding
Responding to the first half of your comment:
Passing BUILD-style Starlark as a string is error-prone because there are no compilation checks where it is written: any errors would be reported in the BUILD file you inject it into.
Consider a WORKSPACE macro like this:
The errors in this code (missing parens for the select, the incorrect package name "//conig", etc) will not be reported from WORKSPACE, but from your code.
Responding to the second half:
Toolchains are not executed by default. I am not sure why it would be a problem for them to be analyzed as part of "bazel build //...".
You can certainly provide helpful macros for users to create their own toolchains simply.
I think, in general, that you are confused about why "select" and related functions are forbidden in WORKSPACE. While we call functions in BUILD and WORKSPACE "macros", they are not macros in the same sense as in LISP or even the C pre-processor: the arguments to Starlark functions are not passed in to the body and then become part of the AST of the generated code. If the "select" function were allowed in the WORKSPACE, it would be executed in the context of the workspace, and there is no configured target or configuration there to allow it to be executed.
Starlark does not have first-class functions as an intentional choice, to prevent BUILD files from becoming too complex and to hep ensure that build rules will eventually halt (and for this reason, Starlark is technically not Turing complete, I believe).