Glibmm install phase passes wrong arguments to meson

Development Language bindings
, , ,
1

I am compiling glibmm on Windows. It compiled succesfully, and now I’m trying to install it. To do that I’m using meson install -C . --destdir=<...>
It seems the install step is running some custom script, which is not even running, because it’s trying to domeson.exe <path_to_a_python_script>, which meson obviously does not recognize and displays the help menu: usage: meson [-h]

Running custom install script 'C:\\Program Files\\Meson\\meson.exe C:/Users/AITOR/Documents/Projects/inkscape-msvc-deps/src/glibmm-2.68.2/untracked/build_scripts/generate-binding.py install_built_h_files C:/Users/AITOR/Documents/Projects/inkscape-msvc-deps/src/glibmm-2.68.2/untracked/glib/glibmm include/glibmm-2.68/glibmm binding bytes bytearray checksum convert date datetime enums fileutils iochannel keyfile markup miscutils module nodetree optioncontext optionentry optiongroup regex shell spawn timezone unicode uriutils variant variantdict variantiter varianttype'
usage: meson [-h]
             {setup,configure,dist,install,introspect,init,test,wrap,subprojects,rewrite,compile,devenv,env2mfile,reprotest,format,fmt,help}
             ...

I think it should be meson runpython ... not just meson ...

2

I asked Claude and I seem to have diagnosed the issue correctly. meson script.py, by accident, DID use to work. In newer versions it doesn’t.

Older glibmm releases must be patched to run with new Meson.

P.S: This seems to be coming from mm-common subproject, not glibmm directly.

3

I am trying to localize where exactly this script is being run and why it’s being run like meson <py>. For now I could localize the issue is coming from subprojects/mm-common/meson.build

4

I could further localize the issue, but I can’t fix it locally because even if I make changes to the scripts, they get updated on every rebuild.

It’s either that python3 = find_program() is undefined at some point, or we’re using python3.path() which is a method from Meson that’s marked as deprecated and is returning null.

Then glibmm is doing:

meson.add_install_script(python3.path(), generate_binding_py, ...)

But python3.path() is null, which turns this into:

meson.add_install_script(null, generate_binding_py, ...)

Which then becomes:

meson ...\generate-binding.py ...
5

python3.path() is not used since glibmm 2.72.0.
Why do you want to build and install glibmm 2.68.2, which is 4.5 years old?

6

Oh, the app I’m building (Inkscape 1.5) requires glibmm-2.68. I wasn’t sure if newer releases would work, but I guess they do? So I’ll try building a more recent version.

7

Indeed, that was the issue and glibmm-2.78.1 compiles and installs fine.

I tried to compile glibmm-2.9 but it seems the maintainers have dropped meson support for that version and I don’t know how I must proceed.

8

Glibmm 2.9 (2005) is older than 2.78 (2024); in 2005, Meson did not exist, and glibmm used Autotools.

9

OOooooohhh damn :person_facepalming: , I thought it was Glibmm 2.90, not 2.9