This is supposed to expose all primitives together, but to do that we
need to actually "use" each variable in `__all__`, which we... didn't.
Sorry about that.
Strictly speaking code restructuring isn't needed, but making this PEP8
compliant results in indentation of the code that reduces the
readability. By moving the offending code on the outside of the method
call, the readability is maintained.
This is generally a bad idea, e.g. it causes OSError on freebsd.
It also gets ignored by solaris and thus causes unittest failures.
The proper solution is to simply reject any attempt to set this, and log a
warning.
The install_emptydir function does apply the mode as well, and since it
is a directory it actually does something. This is the only place where
we don't reset the mode.
Although install_subdir also installs directories, and in theory it
could set the mode as well, that would be a new feature. Also it doesn't
provide much granularity and has mixed semantics with files. Better to
let people use install_emptydir + install_subdir.
Fixes#5902
Generally plumb through the values of get_option() passed to
install_dir, and use this to establish the install plan name. Fixes
several odd cases, such as:
- {datadir} being prepended to "share" or "include"
- dissociating custom install directories and writing them out as
{prefix}/share/foo or {prefix}/lib/python3.10/site-packages
This is the second half of #9478Fixes#10601
`configure_file` is both an extremely complicated implementation, and
a strange place for copying. It's a bit of a historical artifact, since
the fs module didn't yet exist. It makes more sense to move this to the
fs module and deprecate this `configure_file` version.
This new version works at build time rather than configure time, which
has the disadvantage it can't be passed to `run_command`, but with the
advantage that changes to the input don't require a full reconfigure.
This was never meant to work, it's an implementation detail of using
`importlib.import_module` and that our modules used to be named
`unstable_` that this ever worked.
Thanks to `ModuleInfo`, all modules are just named `foo.py` instead of
`unstable_foo.py`, which simplifies the import method a bit. This also
allows for accurate FeatureNew/FeatureDeprecated use, as we know when
the module was added and if/when it was stabilized.
Instead of using FeatureNew/FeatureDeprecated in the module.
The goal here is to be able to handle information about modules in a
single place, instead of having to handle it separately. Each module
simply defines some metadata, and then the interpreter handles the rest.
This error message was quite confusing when triggered by
use of an absolute path to the include dir of an external dependency
(numpy in my case). Changing that to a relative dir also isn't
a solution, because Meson will *not* do the "busywork to make paths
work" that the error message says it will.
We have to handle this, because Windows needs to link to the implib of
the executable (???) in order to create a shared module. This is
explicitly checked for and handled in the backend, and creating a build
target with `link_with: some_exe` still works, even. But updating
declare_dependency to typed_kwargs neglected to take that into account,
so creating a convenience interface for those same arguments failed.
We can use this lots of places, and it's always the same kwarg. There
doesn't seem to be a point in naming it badly, then evolving it to the
standard name in the one place it is currently used. This made it not
shareable.
The check for whether or not a file is allowed to be accessed from a
subproject fails if the subproject is accessed via a symlink. Use the
absolute path of the subproject without resolving symlinks to fix the
check.
Extend unit test 106 to check for this in the future.
At several points in the code base, f-strings are not correctly expanded
due to missing 'f' string prefix. This fixes all the occurrences I could
find.
When a subproject is disabled on the initial configuration we should not
add it into self.coredata.initialized_subprojects because that will
prevent calling self.coredata.init_builtins() on a reconfigure if the
subproject gets enabled.
Fixes: #10225.
Fix "Tried to grab file outside current (sub)project" error when subproject exists within
a source tree but it is used through a symlink. Using subprojects as symlinks is very useful
feature when migrating an existing codebase to meson that all sources do not need to be
immediately moved to subprojects folder.
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 11f9638035 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
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 f34013fb08.
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.
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
...
```
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.
Eli Schwartz