The size of WINEPATH is limited (1024 [until recently]), we
can very easily reach that limit, and even the new one (2048) so
try to keep path as small as possible by using the shortPath
version of paths.
Also assert that we do not reach the new hard limit.
And avoid having duplicates in the list of path.
[until recently]: https://bugs.winehq.org/show_bug.cgi?id=45810
"exe.is_cross and exe.needs_exe_wrapper" is the same condition under which
meson chooses whether to include the exe_wrapper. meson_exe has an assertion
for that, but now that meson_exe does not need anymore exe.is_cross,
we can simplify the code if we just "trust" meson to do the right thing.
Remove both fields from ExecutableSerialisation and just test the presence
of the wrapper, and also remove the executable basename which is only
used to "beautify" an assertion failure.
Move the magic to execute jar and .exe files from "meson --internal exe"
to the backend, so that "ninja -v" shows more clearly what is happening.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If meson_exe is only being used to capture the output of the command,
we can skip going through a pickled ExecutableSerialization object.
This makes "ninja -v" output more useful.
We used to immediately try to use whatever exe_wrapper was defined in
the cross file, but some people generate the cross file once and use
it for several projects, most of which do not even need an exe wrapper
to build.
Now we're a bit more resilient. We quietly fall back to using
non-exe-wrapper paths for compiler checks and skip the sanity check.
However, if some code needs the exe wrapper, f.ex., if you run a built
executable using custom_target() or run_target(), we will error out
during setup.
Tests will, of course, continue to error out when you run them if the
exe wrapper was not found. We don't want people's tests to silently
"pass" (aka skip) because of a bad CI setup.
Closes https://github.com/mesonbuild/meson/issues/3562
This commit also adds a test for the behaviour of exe_wrapper in these
cases, and refactors the unit tests a bit for it.
We already have code to fetch and find binaries specified in a cross
file, so use the same code for exe_wrapper. This allows us to handle
the same corner-cases that were fixed for other cross binaries.
When the exe runner is `wine` or `wine32` or `wine64`, etc.
This allows people to run tests with wine.
Note that you also have to set WINEPATH to point to your custom
prefix(es) if your tests use external dependencies.
Closes https://github.com/mesonbuild/meson/issues/3620
The output may be a binary data stream, not subject to any locale
encoding. This avoids any encoding errors that might arise as a result.
Also fixes github issue #2868.
Instead of adding it everywhere manually, create a wrapper called
mesonlib.Popen_safe and use that everywhere that we call an executable
and extract its output.
This will also allow us to tweak it to do more/different things if
needed for some locales and/or systems.
Closes#1079
For commands that always output to stdout and don't have a "-o" or
"--output" or some other similar option, this 'capture' setting allows
the build to capture the result and place it in the output file.
When a CustomTarget is run with a command that is an executable built
by the project which also has a DLL built in the same project as a
dependency, the EXE can't run on Windows because the DLL can't be found.
On UNIX-like systems, we set the RPATH using the linker so these
dependencies can be found, but on Windows the only way is to set the
PATH environment variable.
The same problem exists for tests, so we reuse that infrastructure by
creating a new meson_exe.py script that can be used as a wrapper to run
CustomTarget commands on Windows. This can later also be extended to add
support for setting an environment while calling the command needed to
generate a CustomTarget: https://github.com/mesonbuild/meson/issues/266
Daniel Mensinger