Idiomatic way to use python scripts in custom_target and similar.

[LunarLambda]

https://mesonbuild.com/Use-of-Python.html#cross-platform-tooling suggests that for portability, additional build tooling should be written in Python, since it is (for the time being) a hard dependency of meson.

However, I'm not sure what the 'idiomatic' way to use said scripts is. A shebang line (#!/usr/bin/python3 or #!/usr/bin/env python3) would be most straightforward, but I would assume it would break on certain platforms (mostly Windows, but also things like NixOS, and other less conventional platforms).

There's the python module and its find_installation() method. Is that the expected way to do it?

In my case, the script(s) also need to be run through configure_file() first, and I find

pymod = import('python')

py3 = pymod.find_installation('python3', required: true)

script = configure_file(...)

custom_target(
  # ...
  command: [py3, script, ...])

to be a little boilerplate-heavy for more anything more complex than this heavily reduced example. Particularly the (apparent) need to specify the py3 interpreter on every command, which could easily be forgotten about, especially when documentation (External Commands, find_program()) suggests using shebangs rather than specifying the interpreter.

How does meson deal with shebangs on Windows? Are they portable, somehow?

[eli-schwartz]

On Windows, script files are by definition non-executable. On Linux, they are non-executable if they don't have the executable bit.

In both cases, Meson will open up the file and scan it for a shebang on the first line, and run the script using the interpreter specified in the shebang. If that interpreter ends in "python3", (including if the shebang uses /usr/bin/env) it will use Meson's own sys.executable as the interpreter.

On Linux, if the file has the executable bit, it is simply run as is, which works in most cases, probably even NixOS, as long as you use env to cope with the BSDs where python is in /usr/local/bin, and NixOS where it is presumably inside a store path somewhere and made available by propagating the interpreter package as a build input.

...

tl;dr

Use shebangs, and if you wish to be extra extra extra extra sure, remove the executable bit.

[LunarLambda]

I see, thank you. Out of curiousity, are there any other 'special shebangs' meson handles, or is only python3 special?

[eli-schwartz]

See https://github.com/mesonbuild/meson/blob/master/mesonbuild/programs.py#L179

tl;dr

No.

[vpoinot]

I am actually trying to use this mechanism to generate a source file, and I cannot get it work...
Some details:

• I have a subproject (sqlpp11) that has a meson.build with the line:

meson.override_find_program('sqlite2cpp', files('scripts/sqlite2cpp.py'))

• in my main project's meson.build, I then have:

sqlite2cpp = find_program('sqlite2cpp', required: true)

schema = custom_target('generate-schema',
                       input: 'schema.sql',
                       output: 'schema.h',
                       command: [ sqlite2cpp, '-identity-naming', '@INPUT@', '@OUTPUT@', 'stox' ])

stox = executable('stox',
                  sources: [ 'main.cpp', schema ],
                  dependencies: boost)

• when I run meson, it does try to generate my schema.h file using my custom target, but it does this way:

[1/2] /home/vincent/devl/stox/subprojects/sqlpp11-0.64/scripts/sqlite2cpp.py -identity-naming ../../../schema.sql schema.h stox
FAILED: schema.h 
/home/vincent/devl/stox/subprojects/sqlpp11-0.64/scripts/sqlite2cpp.py -identity-naming ../../../schema.sql schema.h stox
/bin/sh: ligne 1: /home/vincent/devl/stox/subprojects/sqlpp11-0.64/scripts/sqlite2cpp.py: Permission denied

i.e. it does not try to use the interpreter python3 which is present in the shebang of the sqlite2cpp.py script in this form (which, from what I understand, is understood by meson):

#!/usr/bin/env python3

Note that the sqlite2cpp.py script has its executable bit unset (as the "permission denied" error proves it), which should trigger the execution of the script through the interpreter.

(I am on Linux/Fedora, using meson 1.4.1)

Am I doing something wrong? or is there a bug somewhere?

[eli-schwartz]

For future readers: this was raised as a dedicated question at #13907 and I answered it there. The tl;dr is that using meson.override_find_program(..., files(...)) doesn't work, but meson.override_find_program(..., find_program(...)) does work.