Getting value of environment variable

[voidtrance]

I've done some searching on this but I can find a definitive answer and/or example.

How can I get the value of an environment variable inside a meson.build file. I want perform some custom actions based on an environment variable.

[dcbaker]

Please don't. Meson isn't designed to be configured based on environment variables, but on command line (or machine file) specified options, or based on information about the build/host/target machines.

[voidtrance]

I didn't realize there was an environment variable set for python "editable installs"?

As a matter of curiosity, what's special about those anyway, that you can't just do what most builds do and point your IDE to the primary compile_commands.json created in the build directory?

The directory where the file is created is not static. It's based on the CPython version being used. So, it could change over the life of the project. Also, I use emacs and configuring it to auto-find the directory with the file looks like a pain. To me, it just seems simpler to add a custom rule to copy the file to the top directory.

To make matters worse (for me), I am using a mounted filesystem that does not support symlinks, so I can't just create a symlink to the file and forget about it.

[eli-schwartz]

The directory where the file is created is not static. It's based on the CPython version being used. So, it could change over the life of the project. Also, I use emacs and configuring it to auto-find the directory with the file looks like a pain. To me, it just seems simpler to add a custom rule to copy the file to the top directory.

The file is always created at the top of the builddir -- it has no relation to cpython versions.

The builddir may be created in arbitrary locations though -- from recollection, meson-python will create a random one using the tempfile module, which again has nothing to do with cpython version. But it has an option to pass in a builddir name that you would rather use, so you can make this be a stable location.

[voidtrance]

The directory where the file is created is not static. It's based on the CPython version being used. So, it could change over the life of the project. Also, I use emacs and configuring it to auto-find the directory with the file looks like a pain. To me, it just seems simpler to add a custom rule to copy the file to the top directory.

The file is always created at the top of the builddir -- it has no relation to cpython versions.

The builddir may be created in arbitrary locations though -- from recollection, meson-python will create a random one using the tempfile module, which again has nothing to do with cpython version. But it has an option to pass in a builddir name that you would rather use, so you can make this be a stable location.

Umm, I don't think so:

# ls -al build
total 20
drwxrwxrwx. 1 1027 users  48 Sep 30 11:15 .
drwxrwxrwx. 1 1027 users 428 Oct 21 08:47 ..
drwxrwxrwx. 1 1027 users 296 Oct 17 16:01 cp312
-rwxrwxrwx. 1 1027 users  94 Sep 30 11:15 .gitignore
-rwxrwxrwx. 1 1027 users 110 Sep 30 11:15 .hgignore
#  ls -al build/cp312/
total 424
drwxrwxrwx. 1 1027 users    296 Oct 17 16:01 .
drwxrwxrwx. 1 1027 users     48 Sep 30 11:15 ..
-rwxrwxrwx. 1 1027 users  19843 Oct 16 20:13 build.ninja
-rwxrwxrwx. 1 1027 users   8731 Oct 16 20:13 compile_commands.json
drwxrwxrwx. 1 1027 users     14 Sep 30 11:15 controllers
drwxrwxrwx. 1 1027 users     20 Sep 30 11:15 emulator
drwxrwxrwx. 1 1027 users     36 Sep 30 11:15 frontends
drwxrwxrwx. 1 1027 users      0 Sep 30 11:15 lib
drwxrwxrwx. 1 1027 users    496 Oct 16 20:13 meson-info
drwxrwxrwx. 1 1027 users     26 Sep 30 11:15 meson-logs
drwxrwxrwx. 1 1027 users    396 Oct 16 20:13 meson-private
-rwxrwxrwx. 1 1027 users     40 Oct 16 20:13 meson-python-native-file.ini
-rwxrwxrwx. 1 1027 users 351588 Oct 17 16:01 .ninja_deps
-rwxrwxrwx. 1 1027 users   6681 Oct 17 16:01 .ninja_log
drwxrwxrwx. 1 1027 users     14 Sep 30 11:15 src

[eli-schwartz]

https://github.com/mesonbuild/meson-python/blob/99ca98dc518f54d91766bfdb2d364ea163c16eca/mesonpy/__init__.py#L941-L947

[QuLogic]

The builddir may be created in arbitrary locations though -- from recollection, meson-python will create a random one using the tempfile module, which again has nothing to do with cpython version. But it has an option to pass in a builddir name that you would rather use, so you can make this be a stable location.

Not for editable installs; those are in build/<python tag> where <python tag> is cp311 for CPython 3.11, pp38 for PyPy 3.8, etc.

[dimpase]

How about setting an environment variable?

I need to set LDFLAGS to set rpath for a dependency, a dylib at a non-standard location, because, for instance, I cannot otherwise run compiler.run() to test things involving the dylib in question.

Yes, I can set LDFLAGS externally to meson.build, but this is messy.
I thought I can use env.set('LDFLAGS', 'foobar') in environment(), but the docs on this are not clear to me, and trials and errors haven't led me anywhere.

[dimpase]

in the corresponding dependency I have all of these set in link_args, but these appear to be either ignored, or incorrectly used

[dimpase]

compiler.run(..., args: ['-Wl,-rpath=....', '-L/path/to/dep'])

Can be used.

it doesn't work, while passing the same with the external LDFLAGS does. I don't know why. How does one keep output.exe produced by compiler.run() for inspection? (I'd like to run ldd on it)

In the log I see

Running compile:
Working directory:  /home/dima/software/cypari2/build/meson-private/tmpsenf3d3n
Code:

#include <stdio.h>
#include <pari/pari.h>
int main(void) {
  pari_init(1000000, 2);
  GEN v = pari_version();
  const char *version = GENtostr(pari_version());
  pari_printf("%s",version);
  pari_close();
  return 0;
}

----

Command line: `cc -I/home/dima/software/pari/include /home/dima/software/cypari2/build/meson-private/tmpsenf3d3n/testfile.c -o /home/dima/software/cypari2/build/meson-private/tmpsenf3d3n/output.exe -D_FILE_OFFSET_BITS=64 -O0 -std=c17 '-Wl,-rpath=/home/dima/software/pari/lib -L/home/dima/software/pari/lib' '-Wl,-rpath=/home/dima/software/pari/lib -L/home/dima/software/pari/lib -lpari' -Wl,--start-group /home/dima/software/pari/lib/libpari.so /usr/lib64/libgmp.so -Wl,--end-group` -> 0
Program stdout:


Program stderr:

/home/dima/software/cypari2/build/meson-private/tmpsenf3d3n/output.exe: error while loading shared libraries: libpari-gmp.so.9: cannot open shared object file: No such file or directory


meson.build:98:18: ERROR: Could not run pari version

[eli-schwartz]

Regardless, per the users guide to the library, section 5.9 Globals related to PARI configuration, I would personally recommend computing the version based on the constants from paricfg.h, which should be doable without running a binary, meaning e.g. it works fine via cross.

How does one keep output.exe produced by compiler.run() for inspection? (I'd like to run ldd on it)

It uses TemporaryDirectory, but in theory should be totally reproducible given:

• the source file content from the log
• the compiler command from the log

Did this not reveal anything?

$ mkdir -p /home/dima/software/cypari2/build/meson-private/tmpsenf3d3n && cd /home/dima/software/cypari2/build/meson-private/tmpsenf3d3n

$ cat << _EOF_ > testfile.c 
#include <stdio.h>
#include <pari/pari.h>
int main(void) {
  pari_init(1000000, 2);
  GEN v = pari_version();
  const char *version = GENtostr(pari_version());
  pari_printf("%s",version);
  pari_close();
  return 0;
}
_EOF_


$ cc -I/home/dima/software/pari/include /home/dima/software/cypari2/build/meson-private/tmpsenf3d3n/testfile.c -o /home/dima/software/cypari2/build/meson-private/tmpsenf3d3n/output.exe -D_FILE_OFFSET_BITS=64 -O0 -std=c17 '-Wl,-rpath=/home/dima/software/pari/lib -L/home/dima/software/pari/lib' '-Wl,-rpath=/home/dima/software/pari/lib -L/home/dima/software/pari/lib -lpari' -Wl,--start-group /home/dima/software/pari/lib/libpari.so /usr/lib64/libgmp.so -Wl,--end-group

$ ldd output.exe

[dimpase]

what I also found out that meson-python puts something in native-file which breaks -Dc_link_args, it really pushes one towards using LDFLAGS explicitly. (I just opened an issue in meson-python repo about it)

c_link_args is also rather strange, as I can perfectly compute its value in `meson.build' from another option value, but I do not seem to have a way to do it.

[dimpase]

I would personally recommend computing the version based on the constants from paricfg.h

Over the years we have had so much fun from getting wrong dylibs linked in wheels, that we really want to check that it's done correctly - but compiler.run makes it exceedingly difficult to do, as there is no way to get the precise environment used by meson-python for a test :[

[dimpase]

getting the value of an environment variable is easy via meson.options. Put the following in meson.options

option(
  'foobarval',
  type: 'string',
  value: '',
  description: 'value of FOOBAR'
)

Invoke meson as follows: meson setup <builddir> -Dfoobarval=$FOOBAR
Then in meson.build you can get the value of FOOBAR:

foobar = get_option('foobarval')