diff options
author | Eli Schwartz <eschwartz@archlinux.org> | 2023-03-09 15:28:18 -0500 |
---|---|---|
committer | Xavier Claessens <xclaesse@gmail.com> | 2023-03-28 09:12:02 -0400 |
commit | a7930a2cd7a4f72f964541a4b65a988215def7b9 (patch) | |
tree | 61227a11cd2f3b4c70d72f1aaad4a9c1303eb799 /test cases/failing/74 link with shared module on osx | |
parent | 3070bd49a28ae62a4d1ee9828cd658d9782fb17e (diff) | |
download | meson-a7930a2cd7a4f72f964541a4b65a988215def7b9.zip meson-a7930a2cd7a4f72f964541a4b65a988215def7b9.tar.gz meson-a7930a2cd7a4f72f964541a4b65a988215def7b9.tar.bz2 |
backends: fix bug where meson_exe crashed if constructed with found programs
Because we base the pickled data name on the name property of the
command being run... and for built targets, `exe.name` is always just
the name. However, for an ExternalProgram this is just whatever string
we searched for, so, NOT just the basename.
This became a bigger issue once we started using generator() with the
actual program in commit 6aeec808367f05463394e30a8d40834e97c7afc0,
rather than first casting it to a string, because the VS backend
*always* uses the meson_exe approach for various reasons related to VS
being VS.
Outside of that, it's difficult to actually get an ExternalProgram
object passed to meson_exe -- CustomTarget lowers it to a string,
capture is handled via argparse instead of pickling, etc.
Fixes #11593
Diffstat (limited to 'test cases/failing/74 link with shared module on osx')
0 files changed, 0 insertions, 0 deletions