If a test program forks a child, the pipes might remain open and
"await stdo_task"/"await stde_task" will never complete in
SingleTestRunner._run_cmd().
Instead, catch them in TestSubprocess.wait() so that the whole
process group is killed.
Fixes: #8533
Reported-by: Bastien Nocera <hadess@hadess.net>
This fix issue when using --wipe and the machine file was passed as a
pipe and written locally, or when the file was resolved in XDG_DATA_HOME
or XDG_DATA_DIRS.
Fixes: #8560
Dependencies is already a large and complicated package without adding
programs to the list. This also allows us to untangle a bit of spaghetti
that we have.
If a custom_target output is a directory, we install it as a directory,
not as a file. And, we try to track subdirectories which are created so
uninstalling works. But one directory creation did not go through
DirMaker, in the case where the output directory does not have any
further subdirectories.
Consolidate on makedirs, since I don't see much point in using os.mkdir
right here.
This requires quite a complex and messy logic.
As @dcbaker suggested in #8491, this could be replaced by
an abstraction over linker flags instead of having GNU flags
translated.
get_non_matching_default_options is checking a string from
project_default_options against a validated value from
coredata.options.
Passing the string to validate_value ensures that the comparison
is sound; otherwise, "false" might be compared against False
and a bogus difference is printed.
When reverting from 0.57 to 0.56, one can see an error like this:
File /Users/pm215/src/qemu-for-merges/meson/mesonbuild/coredata.py,
line 1016, in load
obj = pickle.load(f)
ModuleNotFoundError: No module named 'mesonbuild.mesonlib.universal';
'mesonbuild.mesonlib' is not a package
FAILED: build.ninja
The reason is that the old version fails to resolve mesonbuild.mesonlib,
which is a similar situation to the existing AttributeError check. Raise
a MesonException for ModuleNotFoundError as well, so that reconfiguration
proceeds using cmd_line.txt.
Previously builds would *potentially* get sammed with messaging at
configure time that duplicate entries in an array would be an error in
the future, and the cause was because the same entries were getting
added over and over to pkg_config_path.p
This is a useful thing to document. I wasn't really sure where to put
it, but since it's developer oriented I figured in the code itself was
probably more useful and more likely to be seen than in the markdown
that generates the website.