| Age | Commit message (Collapse) | Author |
|---|
|
When referring to the custom_target docs, we want to point to the docs
on the function, not the docs on the returned method.
|
|
Logically, i18n.merge_file cannot ever take a MULTI_OUTPUT_KW, but it
does take a CT_OUTPUT_KW-like interface.
Actually trying to pass multiple merge_file outputs causes the
msgfmthelper script to be entirely malformed in the arguments it
accepts, and treat the broken one like a --flag, then exit with argparse
errors.
Even if we somehow assumed that somehow it was designed to actually
allow this, msgfmt doesn't support conceptually passing multiple outputs
so that would be a msgfmt error instead of an error inside the guts of
`meson --internal msgfmthelper`.
Same logic applies again for the itstool command and the itstool
internal helper.
Catch this error at configuration time by using the single-output kwarg
form.
Likewise, it's totally nonsense to accept multiple install_dir or
install_tags, and ever since commit 11f96380351a88059ec55f1070fdebc1b1033117
the CustomTarget itself won't even check this.
|
|
CT_OUTPUT_KW is the same OUTPUT_KW we use in lots of places. The most
distinctive thing about it is not that it's part of custom_target
(basically any other function that uses such a kwarg follows the same
rules due to using CustomTarget under the hood), but the fact that it
takes multiple outputs.
|
|
We validate a few things here, such as the non-presence of '@INPUT' in
an output name. These got moved out of the CustomTarget constructor in
commit 11f96380351a88059ec55f1070fdebc1b1033117 and into KwargInfo, but
only for kwargs that took multiple values. This caused configure_file()
and unstable_rust.bindgen() to stop checking for this.
Add a shared single-output KW and use it in both places. This now
dispatches to _output_validator.
configure_file now validates subdirectories in output names the same way
we do elsewhere, directly in the typed_kwargs and by specifying the
erroring kwarg.
|
|
Or any other reserved names. We check in add_target that the primary
name of any build target isn't on the forbidden list, but custom_target
allows names that are distinct from the output filenames, so we need to
check those too.
We would eventually still error out all the way at the end, with:
```
ERROR: Multiple producers for Ninja target "all". Please rename your targets.
```
But, if we can check that early and provide the underlying reason
(reserved name) alongside actually useful debugging info (a line
number), then why not?
Refactor the check into a small helper function in the process.
|
|
We don't want to allow targets that conflict with:
- our aliased meson-* targets for phony commands
- any meson-*/ directories we create for internal purposes
We do want to allow targets such as:
- our own meson-*.X manpages
There are a couple routes we could take.
Using a better restriction, such as `meson-internal__*`, is trivially
done for our aliased targets, but changing directory names is...
awkward. We probably cannot do this, and doing the former but not the
latter is not very useful.
We could also carefully allow patterns we know we won't use, such as
file extensions, but which the manpages need, which works for our
directories and for many aliased targets, but run_target() is
user-specified and can be anything.
Use a hybrid approach to cover both use cases. We will now allow target
names that fulfill *all* the following criteria:
- it begins with "meson-"
- it doesn't continue with "internal__"
- it has a file extension
|
|
Every phony target has a special indirection rule created because ninja
is bad at deleting generated outputs and tries to delete phony outputs
too.
Instead of invoking this as a separate helper post-creation function to
create the alias, wrap NinjaBuildElement and create it behind the
scenes. This simplifies target naming and means one less line at every
single use site.
|
|
|
|
Previously the output of the custom target was always captured
and it was not possible to see the output unless build failed.
|
|
The `install_headers` function now has an optional argument
`preserve_path` that allows installing multi-directory
headerfile structures that live alongside sourcecode with a
single command.
For example, the headerfile structure
headers = [
'one.h',
'two.h',
'alpha/one.h',
'alpha/two.h',
'alpha/three.h'
'beta/one.h'
]
can now be passed to `install_headers(headers, subdir: 'mylib', preserve_path: true)`
and the resulting directory tree will look like
{prefix}
└── include
└── mylib
├── alpha
│ ├── one.h
│ ├── two.h
│ └── three.h
├── beta
│ └── one.h
├── one.h
└── two.h
Fixes #3371
|
|
We have two checks for the type accepted here. One is the basic
typed_kwargs type-checking, which declares it accepts:
str | include_directories
The other is the custom validator which further narrows it to strings
with certain option-like properties (needs to be an = assignment).
The former is obviously wrong, which doesn't really matter all that much
but still isn't very nice...
Introduced in commit f34013fb08b8d24d570c96084c5d58c5eaf4f5da.
|
|
override_options makes no sense for custom_target as we don't use it for
anything. Also, this was added in commit c3c30d4b060239654c9b848092692ab346ebed9d
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 e08d73510552fa4a3a087af1a9e5fded8f5749fd 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.
|
|
For maintainer targets, we need some more tools that gettext-tiny
doesn't implement. It's a shame to cause NLS to be completely disabled
in such environments, so instead just issue a warning and continue.
Before 0.62.0 these were never checked for, and would simply fail at
runtime, probably. In theory, the user might install the tools in
between configuring and building, and then the maintainer targets would
begin to work. Return to that behavior -- we still create the targets,
which will *probably* fail, but might not -- and for existing
integrations, failing at `ninja foo-update-po` with "error, program
msgmerge not found" is a bit more discoverable than ninja saying "what
do you mean, there's no such target".
We still have the 0.62.0 preferred behavior of trying to find the
programs, succeeding in all cases other than gettext-tiny, and
guaranteeing that their paths are set up in a machine-file-respecting
manner.
|
|
In the former case, the presence of tools is optional, but triggers a
warning and then no-ops the target. In the latter case, the presence of
the tools is mandatory. But if it was already looked up and discovered
to be missing, we did not actually check that it is found before trying
to use it.
In the case that it isn't found, check again, so that we explicitly
error out with a relevant error message due to setting the required
flag.
Fixes #10320
|
|
Because this is a wrapper script and we could/should do this, we even
have half the infra for it.
|
|
mingw GCC using ld.bfd emits diagnostics that include
"-plugin-opt=-pass-through=-lmoldname" and this triggers a match for
mold when it should not.
Instead, always check the very beginning of the output for the linker
id. This is pretty consistent:
- it is always on stdout
- GCC may put additional things on stderr we don't care about
- swift is bizarre and on some OSes redirects the linker stdout to
swiftc's stderr, but it will still be the only stderr; we didn't even
check stderr at all until commit 712cbe056811ebdf0d7358ba07a874717a1c736f
For gold/bfd linkers, the linker id is always the *second* word, after
the legally mandated "GNU" we already check for.
|
|
|
|
The CI correctly handles documentation changes automatically, it's no
longer necessary to do it by hand.
|
|
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.
|
|
This fixes bogus messages "skipped: feature foo disabled" when
auto_features=disabled. It was reporting the name of the latest
get_option() call instead of the name of the current feature option.
This is especially visible in GStreamer summary where it should show a
different option name for every subproject but instead shows "tools"
everywhere:
```
Subprojects
gst-devtools : NO Feature 'tools' disabled
gst-editing-services : NO Feature 'tools' disabled
...
```
|
|
Which also fixes builds on windows that might produce a .lib instead of
a .a. The error message has been changed to reflect that as well
|
|
Including that we don't accept SharedLibraries or CustomTarget[Index]s
that are a shared library
|
|
This is useful for cases where we treat CustomTargets as linkable
targets, and need to know whether they're going to link statically or
dynamically.
|
|
Since a SharedLibrary can't be statically linked in, we shouldn't allow
the method to complete.
|
|
|
|
- `BuildTarget` should be `SharedLibrary | StaticLibrary`
- Needs to take `CustomTargetIndex` as well as `CustomTarget`
- don't assign to self until values have been converted to the correct
type
|
|
which do not hold BuildTargets, they are `SharedLibrary | StaticLibrary |
CustomTarget | CustomTargetIndex` (whole doesn't accept `SharedLIbrary`)
|
|
|
|
That come to light with some of the changes later in this series,
particularly around dependencies.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Change message
Header <foo.h> has symbol "BAR"
to
Header "foo.h" has symbol "BAR"
with the first part also now in bold. This is more consistent with
other messages like
Has header "foo.h"
and
Checking whether type "foo" has member "bar"
|
|
We were poking directly at the node, so if it was a FunctionNode then
this broke. Instead, just do a reverse lookup in the overrides table to
get the original find_program name.
|
|
TAP version 14 introduced subtests, that are supposedly backward compatible
because "TAP13 specifies that non-TAP output should be ignored". Meson
reported TAP syntax errors based on behavior of "prove" at the time,
but it seems that now "prove" has become a lot more lenient; it even
accepts the following completely bogus input just fine:
---
ok 1
ok 2
x
1..1
---
So do the same and make Meson's parser accept invalid TAP input silently.
Fixes: #10032
|
|
|
|
As we commonly do in other modules
|
|
Which doesn't have `StructuredSources`, as is actually quite common.
|
|
|
|
|
|
|
|
In commit f2d21bf8a98fe4eb528a077f3faf5d68cd35c244 a type annotation was
added that does not exist. The referenced type is present but only as a
dotted name.
|
|
- mismatched method type
- mismatched parameter names
|
|
|
|
|
|
"targetting" is verb-derived adjective, which sort-of-works here, but
makes the whole sentence awkward, because there's no verb. Let's just
use present simple.
|
|
"tried to use" implies that the attempt was not successful, i.e. that meson
ignored the feature. But that is not what happens, apart from the warning the
feature works just fine. The new message is also shorter ;)
|
