Allow macro_name to be speficied as a parameter to configure_file().
This allows C macro-style include guards to be added to
configure_file()'s output when a template file is not given. This change
simplifies the creation of configure files that define macros with
dynamic names and want the C-style include guards.
Also move it into the Jar class. This is an exclusive Jar keyword
argument, and is only used inside java paths, so there's no reason to
have this in all build targets.
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
override_options makes no sense for custom_target as we don't use it for
anything. Also, this was added in commit c3c30d4b06
despite not being allowed in permittedKwargsc3c30d4b0.
For inexplicable reasons, we had a known_kwargs for custom_target that
looped over kwargs and issued a warning, not an error, for unknown
kwargs. It was impossible to ever hit that check to begin with, though,
ever since commit e08d735105 which added
permittedKwargs and obsoleted those manual checks with real errors.
So at one point override_options was specially permitted to be used
without emitting a warning, and then for about half a decade it was an
error, and then based on some dead code it was allowed again for a bit.
But through all this it doesn't do anything and isn't documented.
We accept boolean false to indicate "do not install this one particular
output", but the type checking simply checked if it is a bool. We do
this correctly for configure_file, so copy the same validator from
there.
Because we don't want to pass the Interpreter kwargs into the build
layer. This turned out to be a mega commit, as there's really on elegant
way to make this change in an incremental way. On the nice side, mypy
made this change super easy, as nearly all of the calls to
`CustomTarget` are fully type checked!
It also turns out that we're not handling install_tags in custom_target
correctly, since we're not converting the boolean values into Optional
values!
This removes the ability to use ConfigurationData as a dict, but
restricting the inputs to `str | int | bool`. This may be a little too
soon for this, and we may want to wait on that part, it's only bee 8
months since we started warning about this.
This also cleans up a couple of internal callers of the internal impl
version that don't set the `check` argument, and therefore trigger a
warning about not setting the check argument.
This also includes a few type annotation cleans for the Summary object.
Getting the positional arguments exactly right is impossible, as this is
really a function with two different signatures:
```
summary(value: dictionary): void
summary(key: string, value: any): void
```
We can get close enough in the typed_pos_args by enforcing that there
are two parameters, one required and one optional, and that the first
must be either a dictionary or a string.
This does not convert the build side, or remove any of the checking it
does. We still need that for other callers of custom target. What we'll
do for those is add an internal interface that defaults things, then
we'll be able to have those callers do their own validation, and the
CustomTarget validation machinary can be removed.
Fixes#9096
Currently, EnvironmentVariablesObject is a strange
holder-that's-not-a-holder. This has implicaitons for things that expect
to get an EnvironmentVariables object, as we can't automatically
unholder it, and instead have to to manually do so. Now we can
automatically unholder it, which makes everything much nicer.
Dylan Baker
Xavier Claessens
Arsen Arsenović
Nicholas Vinson
Charles Brunet
Nomura
Eli Schwartz
Josh Soref
David Robillard
Tristan Partin