Re: [libvirt PATCH 2/3] meson: drop explicit python interpreter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

On Tue, Apr 11, 2023 at 11:10 AM Michal Prívozník <mprivozn@xxxxxxxxxx> wrote:
On 4/6/23 17:58, marcandre.lureau@xxxxxxxxxx wrote:
> From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx>
>
> meson wraps python scripts already on win32, so we end up with these
> failing commands:
>
> [1/359] "C:/msys64/ucrt64/bin/meson" "--internal" "exe" "--capture" "src/util/virkeycodetable_atset1.h" "--" "sh" "C:/msys64/home/marca/src/libvirt/scripts/meson-python.sh" "C:/msys64/ucrt64/bin/python3.EXE" "python" "C:/msys64/home/marca/src/libvirt/src/keycodemapdb/tools/keymap-gen" "code-table" "--lang" "stdc" "--varname" "virKeyCodeTable_atset1" "C:/msys64/home/marca/src/libvirt/src/keycodemapdb/data/keymaps.csv" "atset1"
> FAILED: src/util/virkeycodetable_atset1.h
> "C:/msys64/ucrt64/bin/meson" "--internal" "exe" "--capture" "src/util/virkeycodetable_atset1.h" "--" "sh" "C:/msys64/home/marca/src/libvirt/scripts/meson-python.sh" "C:/msys64/ucrt64/bin/python3.EXE" "python" "C:/msys64/home/marca/src/libvirt/src/keycodemapdb/tools/keymap-gen" "code-table" "--lang" "stdc" "--varname" "virKeyCodeTable_atset1" "C:/msys64/home/marca/src/libvirt/src/keycodemapdb/data/keymaps.csv" "atset1"
>
> If LC_ALL, LANG and LC_CTYPE need to be set, it would probably be better
> to use a meson environment() instead.
>
> Signed-off-by: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx>
> ---
>  docs/manpages/meson.build | 4 ++--
>  docs/meson.build          | 6 ++----
>  src/admin/meson.build     | 4 ++--
>  src/esx/meson.build       | 4 ++--
>  src/hyperv/meson.build    | 2 +-
>  src/meson.build           | 8 ++++----
>  src/util/meson.build      | 4 ++--
>  7 files changed, 15 insertions(+), 17 deletions(-)

After this, there are still some occurrences of meson_python_prog or
python3_prog left; mostly in locations which are never built on Windows
(e.g. src/qemu/, src/network/ and so on. But is it worth removing them too?


If we don't have a good reason for this extra wrapping, yes. Is gitlab CI covering enough to validate the change? Someone more familiar with libvirt build environments should know better.

thanks

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux