Using generator() with python3

[Richard Hughes]

I'm currently using:

cmdpy = find_program(join_paths(meson.project_source_root(), 'cmd.py'))
cmd = generator(cmdpy,
output : ['@BASENAME@-struct.c', '@BASENAME@-struct.h'],
arguments : ['@INPUT@', '@OUTPUT0@', '@OUTPUT1@'],
)

...but this is being run by the system python, rather than the
configured python install (e.g. what
import('python').find_installation('python3')) would detect. Using the
system python version doesn't work on macos and freebsd like it does
on Linux.

Is there a way to use a generator with the correct python binary? Thanks,

Richard.

[Richard Hughes]

Answering my own question, this seems to work:

foogen = generator(python3,

output : ['@BASENAME@-struct.c', '@BASENAME@-struct.h'],
arguments : [

join_paths(meson.project_source_root(), 'libfwupdplugin', 'foogen.py'),

'@INPUT@',
'@OUTPUT0@',
'@OUTPUT1@',

],
)

Sorry for the noise.

Richard

[Daniele Nicolodi]

On 23/04/23 21:53, Richard Hughes wrote:
> Answering my own question, this seems to work:
>
> foogen = generator(python3,
> output : ['@BASENAME@-struct.c', '@BASENAME@-struct.h'],
> arguments : [
> join_paths(meson.project_source_root(), 'libfwupdplugin', 'foogen.py'),

This is not really the idiomatic way to do this in Meson. In general,
every time you want to use meson.project_source_root() look again for a
better way of doing the same. In this case to get the path of your
script you can simply do:

foogen_py = files('libfwupdplugin/foogen.py')

Cheers,
Dan

[Eli Schwartz]

On 4/23/23 3:08 PM, Richard Hughes wrote:
> I'm currently using:
>
> cmdpy = find_program(join_paths(meson.project_source_root(), 'cmd.py'))
> cmd = generator(cmdpy,
> output : ['@BASENAME@-struct.c', '@BASENAME@-struct.h'],
> arguments : ['@INPUT@', '@OUTPUT0@', '@OUTPUT1@'],
> )
>
> ...but this is being run by the system python, rather than the
> configured python install (e.g. what
> import('python').find_installation('python3')) would detect. Using the
> system python version doesn't work on macos and freebsd like it does
> on Linux.

When using find_program on the script:
- join_paths is unnecessary here, probably, because it will be found
relative to the current meson.build file first
- if the cmd.py is an executable file, it will be run as-is, regardless
of the shebang and what programming language it is written in
- if the cmd.py is not an executable file, meson will parse the shebang,
and specially handle "python3" to run it with the same version of
python that meson itself uses, to guarantee that python scripts always
work (even on Windows, where python may not be installed)


When using find_installation with the "python3" argument, meson will
find a literal "python3" executable on PATH and use that as the command.
This is effectively the same as the `#!/usr/bin/env python3` approach.
But the latter also respects machine file overrides.

Does this script need non-stdlib modules?


--
Eli Schwartz

[Richard Hughes]

On Sun, 23 Apr 2023 at 21:14, Eli Schwartz <eschw...@gmail.com> wrote:
> - join_paths is unnecessary here, probably, because it will be found
> relative to the current meson.build file first

Okay, I'll try and remove a lot of the project_source_root stuff too.

> - if the cmd.py is an executable file, it will be run as-is, regardless
> of the shebang and what programming language it is written in

It is executable.

> - if the cmd.py is not an executable file, meson will parse the shebang,
> and specially handle "python3" to run it with the same version of
> python that meson itself uses, to guarantee that python scripts always
> work (even on Windows, where python may not be installed)

I'm guessing chmod-x-ing this file might work too, although that makes
local development of that feature a little harder to do. Is there a
way of forcing the not-executable flow?

> Does this script need non-stdlib modules?

Yes, unfortunately.

Richard.