Make the `devenv` environment available from within `meson.build`

[joukewitteveen]

Feature request In my tests, I want to invoke a built executable. I can express the dependence of the test on the executable with the depends argument, but I should invoke the uninstalled executable in the meson devenv environment. As far as I can tell, this environment is not available from within meson, so I cannot simply add env: meson.devenv() to the test definition.

Sample usage meson.build:

project('tutorial', 'c')
demo_exe = executable('demo', 'main.c')

test('invoke demo', find_program('invoke_demo.sh'),
  depends: demo_exe,
  env: meson.devenv(),
  workdir: meson.global_build_root())

invoke_demo.sh:

#!/bin/sh

./demo

We could change invoke_demo.sh into running meson devenv ./demo (or meson run, with #10928), but that only works if meson can be found.

[QuLogic]

You can use meson devenv ./demo if you pass it to your test from meson.build, as find_program('meson') can be used to find the current meson.

In fact, do you need the script at all? It seems like everything could go in the test call:

test('invoke demo', find_program('meson'),
  args: ['devenv', '-C', meson.global_build_root(), demo_exe])

[joukewitteveen]

Of course you don't need it in the example script. It is just an example.

Indeed, you could do

test('invoke demo', find_program('invoke_demo.sh'),
  depends: demo_exe,
  env: {'MESON': find_program('meson').full_path()},
  workdir: meson.global_build_root())

but this still mean invoke_demo.sh needs to be meson-aware. My suggestion is to make it easy to run tests (or anything else that takes an environment argument) in an environment similar to meson devenv.

[bruchar1]

Is it needed only for tests, or is there other usecases? I'm not sure a meson.devenv() function would be possible to implement, since we cannot know the whole context of the devenv at setup time. However, I think having a use_devenv: true argument to test function would make sense. I have few places in my project where I need to call a test executable through meson devenv, and it feels awkward.

[joukewitteveen]

My only use-case is with tests. I understood on the chat that meson-built binaries are portable, but that goes somewhat against my understanding of what devenv is for. In particular, the documentation mentions setting LD_LIBRARY_PATH, which seems like it would be needed for proper testing when shared libraries are at play.

edit: I guess it could even make sense to set a hypothetical use_devenv argument to true by default. At that point, the question becomes whether there are use cases where you don't want to run tests in a devenv environment, and whether the argument is needed at all.

[bruchar1]

I think meson properly set environment variables for the dependencies of the executable used for the test. On Windows, for instance, the path to all shared libraries must go into the PATH env var. The use of the whole devenv would be useful only in specific contexts. Usually, you don't need the "whole" devenv. This is why I think the default should still be false, for backward compatibility, and to prevent setting unnecessary environment variables.

[eli-schwartz]

The real question is of course what specific devenv variables you might need, that aren't ones set via meson.add_devenv() and which could easily be added to an env object for test use at the same time.

My only use-case is with tests. I understood on the chat that meson-built binaries are portable, but that goes somewhat against my understanding of what devenv is for. In particular, the documentation mentions setting LD_LIBRARY_PATH, which seems like it would be needed for proper testing when shared libraries are at play.

It's needed for creating an interactive environment where you can test your own software against an updated version of e.g. development GStreamer.

For all binaries built as part of the ninja build, LD_LIBRARY_PATH is not needed regardless due to the ELF format allowing you to embed that information at link time.

[bruchar1]

I have a python test using an extension module, on Windows. Even if the extension module is in dependencies of the test (and is marked as installable), the extension module and its dependencies are not put in the PATH. It only works if I run it through devenv.