internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: mesonbuild/meson

Issue:
add_test_setup - new environment behavior ?
The behavior of environment for `add_test_setup()` seems
to have changed between 0.44.1 and 0.45.0

Our code using
```meson
add_test_setup('valgrind',
               exe_wrapper : ['valgrind', '--error-exitcode=1', '--leak-check=full'],
               timeout_multiplier : 100)
```
does not work anymore, seems like `os.environ` is not available

Patching like
```meson
e = environment()
e.append('PATH', '', separator : '')
e.append('SHELL', '', separator : '')
e.append('DBUS_SESSION_BUS_ADDRESS', '', separator : '')
add_test_setup('valgrind',
               env : e,
               exe_wrapper : ['valgrind', '--error-exitcode=1', '--leak-check=full'],
               timeout_multiplier : 100)
```
makes all tests pass again (our code uses sd_bus)
I run like: `meson test --setup valgrind`

If we just do meson test, it seems that the full os.environ is available during test


Surely it cannot be correct that test_setup has a different environment ?


Discussion:

Resolving patch:
diff --git a/mesonbuild/build.py b/mesonbuild/build.py
--- a/mesonbuild/build.py
+++ b/mesonbuild/build.py
@@ -290,7 +290,7 @@ def prepend(self, env, name, values, kwargs):
         return value
 
     def get_env(self, full_env):
-        env = {}
+        env = full_env.copy()
         for method, name, values, kwargs in self.envvars:
             env[name] = method(full_env, name, values, kwargs)
         return env
diff --git a/run_unittests.py b/run_unittests.py
--- a/run_unittests.py
+++ b/run_unittests.py
@@ -1020,7 +1020,6 @@ def test_testsetups(self):
         self._run(self.mtest_command + ['--setup=timeout'])
 
     def test_testsetup_selection(self):
-        return
         testdir = os.path.join(self.unit_test_dir, '13 testsetup selection')
         self.init(testdir)
         self.build()


Test patch:
diff --git a/test cases/unit/2 testsetups/envcheck.py b/test cases/unit/2 testsetups/envcheck.py
new file mode 100755
--- /dev/null
+++ b/test cases/unit/2 testsetups/envcheck.py	
@@ -0,0 +1,5 @@
+#!/usr/bin/env python3
+
+import os
+
+assert('PATH' in os.environ)
diff --git a/test cases/unit/2 testsetups/meson.build b/test cases/unit/2 testsetups/meson.build
--- a/test cases/unit/2 testsetups/meson.build	
+++ b/test cases/unit/2 testsetups/meson.build	
@@ -14,6 +14,9 @@ add_test_setup('valgrind',
 buggy = executable('buggy', 'buggy.c', 'impl.c')
 test('Test buggy', buggy)
 
+envcheck = find_program('envcheck.py')
+test('test-env', envcheck)
+
 add_test_setup('empty')
 add_test_setup('onlyenv', env : env)
 add_test_setup('onlyenv2', env : 'TEST_ENV=1')
Repository: mesonbuild/meson

Issue:
get_define should raise a better Error if compiler does not support it.
If one calls `get_define` for the rust compiler the result is a backtrace. We should check if the compiler  has `get_define` defined and raise a better error message if not.


Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers/compilers.py b/mesonbuild/compilers/compilers.py
--- a/mesonbuild/compilers/compilers.py
+++ b/mesonbuild/compilers/compilers.py
@@ -699,6 +699,21 @@ def get_display_language(self):
     def get_default_suffix(self):
         return self.default_suffix
 
+    def get_define(self, dname, prefix, env, extra_args, dependencies):
+        raise EnvironmentException('%s does not support get_define ' % self.get_id())
+
+    def compute_int(self, expression, low, high, guess, prefix, env, extra_args, dependencies):
+        raise EnvironmentException('%s does not support compute_int ' % self.get_id())
+
+    def has_members(self, typename, membernames, prefix, env, extra_args=None, dependencies=None):
+        raise EnvironmentException('%s does not support has_member(s) ' % self.get_id())
+
+    def has_type(self, typename, prefix, env, extra_args, dependencies=None):
+        raise EnvironmentException('%s does not support has_type ' % self.get_id())
+
+    def symbols_have_underscore_prefix(self, env):
+        raise EnvironmentException('%s does not support symbols_have_underscore_prefix ' % self.get_id())
+
     def get_exelist(self):
         return self.exelist[:]
 
diff --git a/mesonbuild/interpreter.py b/mesonbuild/interpreter.py
--- a/mesonbuild/interpreter.py
+++ b/mesonbuild/interpreter.py
@@ -1043,6 +1043,8 @@ def has_member_method(self, args, kwargs):
         'dependencies',
     })
     def has_members_method(self, args, kwargs):
+        if len(args) < 2:
+            raise InterpreterException('Has_members needs at least two arguments.')
         check_stringlist(args)
         typename = args[0]
         membernames = args[1:]


Test patch:
Repository: mesonbuild/meson

Issue:
gdbus_codegen should return two different targets (.c, .h)
With glib<2.56.2, gdbus_codegen() returns twice the same custom_target, with two outputs.

A bug occurs when this return value is used for generate_gir(). The source list then contains twice the .c, and zero times the .h…

Maybe gdbus_codegen() should return two custom_targets, with each one output (once the .c, once the .h).

EDIT : Actually, after reading the source of generate_gir, I suppose the bug is there.

```
                    gir_filelist.write(os.path.join(state.environment.get_build_dir(),
                                                    state.backend.get_target_dir(s),
                                                    s.get_outputs()[0]) + '\n')
```
Why only `s.get_outputs()[0]` ?



Discussion:
Yeah, that `s.get_outputs()[0]` is probably wrong. It should loop over all the outputs and write them all.

Resolving patch:
diff --git a/mesonbuild/modules/gnome.py b/mesonbuild/modules/gnome.py
--- a/mesonbuild/modules/gnome.py
+++ b/mesonbuild/modules/gnome.py
@@ -446,9 +446,10 @@ def generate_gir(self, state, args, kwargs):
                 if hasattr(s, 'held_object'):
                     s = s.held_object
                 if isinstance(s, (build.CustomTarget, build.CustomTargetIndex)):
-                    gir_filelist.write(os.path.join(state.environment.get_build_dir(),
-                                                    state.backend.get_target_dir(s),
-                                                    s.get_outputs()[0]) + '\n')
+                    for custom_output in s.get_outputs():
+                        gir_filelist.write(os.path.join(state.environment.get_build_dir(),
+                                                        state.backend.get_target_dir(s),
+                                                        custom_output) + '\n')
                 elif isinstance(s, mesonlib.File):
                     gir_filelist.write(s.rel_to_builddir(state.build_to_src) + '\n')
                 elif isinstance(s, build.GeneratedList):


Test patch:
Repository: mesonbuild/meson

Issue:
Logging system-calls?
Would there be value in a command-line flag to force Meson to log all `Popen_safe()` system calls, for debugging? (Of course, I can use `strace` in a pinch.)

For reference:
* https://github.com/mesonbuild/meson/blob/fc5e8dfcdae11d23469fd01d878c7c9c30d67d30/mesonbuild/dependencies/base.py -- `class Dependency`, which runs **pkg-config** invisibly
* https://github.com/mesonbuild/meson/blob/fc5e8dfcdae11d23469fd01d878c7c9c30d67d30/mesonbuild/mesonlib.py -- `Popen_safe()`


Discussion:
From #3606:

> Also, pkg-config will usually automatically define the prefix itself, so you don't need to manually define it. 

It's hard for me to know such a detail when I cannot see the actual `pkg-config` call.
I'm willing to submit a pull-request for this. It's *very important*. We spend too much debugging `pkg-config` problems in our builds. We need to know exactly how pkg-config was called.
Sounds like you just want a `mlog.debug()` in `mesonbuild/dependencies/base.py` `PkgConfigDependency:_call_pkgbin()`. I'd be happy to review and merge such a change.

Resolving patch:
diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
--- a/mesonbuild/dependencies/base.py
+++ b/mesonbuild/dependencies/base.py
@@ -520,8 +520,12 @@ def __repr__(self):
                         self.version_reqs)
 
     def _call_pkgbin_real(self, args, env):
-        p, out = Popen_safe(self.pkgbin.get_command() + args, env=env)[0:2]
-        return p.returncode, out.strip()
+        cmd = self.pkgbin.get_command() + args
+        p, out = Popen_safe(cmd, env=env)[0:2]
+        rc, out = p.returncode, out.strip()
+        call = ' '.join(cmd)
+        mlog.debug("Called `{}` -> {}\n{}".format(call, rc, out))
+        return rc, out
 
     def _call_pkgbin(self, args, env=None):
         if env is None:


Test patch:
Repository: mesonbuild/meson

Issue:
Meson detects wrong framework for includes on macOS
When detecting the Qt dependency, which are `.framework`s on macOS, Meson sometimes detects the wrong `.framework` and uses that instead of the real one:

```
c++ -Imodules/modules@@qt_plugin@sha -Imodules -I../VLC/modules -I. -I../VLC/ -I../VLC/include -I/Applications/Qt/5.10.1/clang_64/lib/QtCore.framework.dSYM/Headers -I/Applications/Qt/5.10.1/clang_64/lib/QtGui.framework/Headers -flto -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -std=gnu++11 -O2 -g -mmacosx-version-min=10.10 -DHAVE_CONFIG_H=1 -F/Applications/Qt/5.10.1/clang_64/lib -F/Applications/Qt/5.10.1/clang_64/lib  -MD -MQ 'modules/modules@@qt_plugin@sha/gui_qt_dialogs_provider.cpp.o' -MF 'modules/modules@@qt_plugin@sha/gui_qt_dialogs_provider.cpp.o.d' -o 'modules/modules@@qt_plugin@sha/gui_qt_dialogs_provider.cpp.o' -c ../VLC/modules/gui/qt/dialogs_provider.cpp
```

As you can see, for the include it tries to use `/Applications/Qt/5.10.1/clang_64/lib/QtCore.framework.dSYM/Headers` in one case, which is the path to the dSYM bundle that contains debug information, not the Qt Core framework.


Discussion:
Kind of related to a part of #3402

Resolving patch:
diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
--- a/mesonbuild/dependencies/base.py
+++ b/mesonbuild/dependencies/base.py
@@ -1003,7 +1003,7 @@ def detect(self, name, path):
         for p in paths:
             for d in os.listdir(p):
                 fullpath = os.path.join(p, d)
-                if lname != d.split('.')[0].lower():
+                if lname != d.rsplit('.', 1)[0].lower():
                     continue
                 if not stat.S_ISDIR(os.stat(fullpath).st_mode):
                     continue


Test patch:
Repository: mesonbuild/meson

Issue:
Unhandled exception when passing a program object that wasn't found to run_target
```meson
project('bad_run_target', 'c')

bad_program = find_program('xxxdoesnotexistxxx', required : false)
run_target('bad target', command : [bad_program])
```

```
The Meson build system
Version: 0.47.0.dev1
Source dir: /tmp/mesontest/bad_run_target
Build dir: /tmp/mesontest/bad_run_target/builddir
Build type: native build
Project name: bad_run_target
Project version: undefined
Native C compiler: ccache cc (gcc 8.1.1 "cc (SUSE Linux) 8.1.1 20180523 [gcc-8-branch revision 260570]")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Program xxxdoesnotexistxxx found: NO
Build targets in project: 1
Found ninja-1.8.2 at /usr/bin/ninja
Traceback (most recent call last):
  File "/data/git/meson/mesonbuild/mesonmain.py", line 339, in run
    app.generate()
  File "/data/git/meson/mesonbuild/mesonmain.py", line 114, in generate
    self._generate(env)
  File "/data/git/meson/mesonbuild/mesonmain.py", line 163, in _generate
    intr.backend.generate(intr)
  File "/data/git/meson/mesonbuild/backend/ninjabackend.py", line 220, in generate
    self.generate_target(t, outfile)
  File "/data/git/meson/mesonbuild/backend/ninjabackend.py", line 323, in generate_target
    self.generate_run_target(target, outfile)
  File "/data/git/meson/mesonbuild/backend/ninjabackend.py", line 616, in generate_run_target
    cmd = self.replace_paths(target, cmd)
  File "/data/git/meson/mesonbuild/backend/ninjabackend.py", line 1880, in replace_paths
    for x in args]
  File "/data/git/meson/mesonbuild/backend/ninjabackend.py", line 1880, in <listcomp>
    for x in args]
AttributeError: 'NoneType' object has no attribute 'replace'
```


Discussion:

Resolving patch:
diff --git a/mesonbuild/interpreter.py b/mesonbuild/interpreter.py
--- a/mesonbuild/interpreter.py
+++ b/mesonbuild/interpreter.py
@@ -3088,6 +3088,8 @@ def func_run_target(self, node, args, kwargs):
             if not isinstance(i, (str, build.BuildTarget, build.CustomTarget, dependencies.ExternalProgram, mesonlib.File)):
                 mlog.debug('Wrong type:', str(i))
                 raise InterpreterException('Invalid argument to run_target.')
+            if isinstance(i, dependencies.ExternalProgram) and not i.found():
+                raise InterpreterException('Tried to use non-existing executable {!r}'.format(i.name))
             cleaned_args.append(i)
         name = args[0]
         if not isinstance(name, str):


Test patch:
diff --git a/test cases/failing/81 unfound run/meson.build b/test cases/failing/81 unfound run/meson.build
new file mode 100644
--- /dev/null
+++ b/test cases/failing/81 unfound run/meson.build	
@@ -0,0 +1,4 @@
+project('unfound runtarget')
+
+exe = find_program('nonexisting_prog', required : false)
+run_target('invoke_fail', command : [exe])
Repository: mesonbuild/meson

Issue:
Default value of UserFeatureOption is `enabled` instead of `auto`
According to `meson --help`:

```
  --auto-features {enabled,disabled,auto}
                        Override value of all 'auto' features (default: auto).
```

However, in reality the default value is `enabled`. We should fix it to be `auto`.


Discussion:
Weird, it's set to "auto" by default in the code `'auto_features':   [UserFeatureOption, "Override value of all 'auto' features.", 'auto'],`.
It might be that the default value for `UserFeatureOption` is `enabled` instead of `auto` (when unspecified).
You're right:
```python
    return coredata.UserFeatureOption(name,
                                      description,
                                      kwargs.get('value', 'enabled'),
                                      yielding=kwargs.get('yield', coredata.default_yielding))
```

Resolving patch:
diff --git a/mesonbuild/optinterpreter.py b/mesonbuild/optinterpreter.py
--- a/mesonbuild/optinterpreter.py
+++ b/mesonbuild/optinterpreter.py
@@ -121,7 +121,7 @@ def string_array_parser(name, description, kwargs):
 def FeatureParser(name, description, kwargs):
     return coredata.UserFeatureOption(name,
                                       description,
-                                      kwargs.get('value', 'enabled'),
+                                      kwargs.get('value', 'auto'),
                                       yielding=kwargs.get('yield', coredata.default_yielding))
 
 option_types = {'string': StringParser,


Test patch:
Repository: mesonbuild/meson

Issue:
WARNING: Unknown CPU family 's390x', please report this at https://github.com/mesonbuild/meson/issues/new with theoutput of `uname -a` and `cat /proc/cpuinfo`
This is z13 IBM z Systems (S/390) mainframe

```
$ uname -a
Linux hostname 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:14:23 UTC 2018 s390x s390x s390x GNU/Linux
```

```
$ cat /proc/cpuinfo 
vendor_id       : IBM/S390
# processors    : 4
bogomips per cpu: 3033.00
max thread id   : 0
features	: esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgprs te vx sie 
facilities      : 0 1 2 3 4 6 7 8 9 10 12 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 40 41 42 43 44 45 46 47 48 49 50 51 52 53 55 57 73 74 75 76 77 80 81 82 128 129 131
cache0          : level=1 type=Data scope=Private size=128K line_size=256 associativity=8
cache1          : level=1 type=Instruction scope=Private size=96K line_size=256 associativity=6
cache2          : level=2 type=Data scope=Private size=2048K line_size=256 associativity=8
cache3          : level=2 type=Instruction scope=Private size=2048K line_size=256 associativity=8
cache4          : level=3 type=Unified scope=Shared size=65536K line_size=256 associativity=16
cache5          : level=4 type=Unified scope=Shared size=491520K line_size=256 associativity=30
processor 0: version = FF,  identification = 118F67,  machine = 2964
processor 1: version = FF,  identification = 118F67,  machine = 2964
processor 2: version = FF,  identification = 118F67,  machine = 2964
processor 3: version = FF,  identification = 118F67,  machine = 2964

cpu number      : 0
cpu MHz dynamic : 5000
cpu MHz static  : 5000

cpu number      : 1
cpu MHz dynamic : 5000
cpu MHz static  : 5000

cpu number      : 2
cpu MHz dynamic : 5000
cpu MHz static  : 5000

cpu number      : 3
cpu MHz dynamic : 5000
cpu MHz static  : 5000
```

Interesting things are 'zarch' features, meaning it is a 64bit one (hence s390x), instead of older 31bit s390 (without any linux distro support anymore). And the identification/machine, some other shell like machine/cpuinfo linux thing has tables to decode all that already i think.


Discussion:
Are all the CPUs in this family called `s390x` and are there different models with more specific names (like the way arm has armv7sle and a dozen more)?
all CPUs are always `s390x` since a long time ago, and are likely to stay that way. It is guaranteed to be backwards/forwards compatible forever too. Newer mainframes continue to gain more features/facilities, which is always exposed as flags with runtime detection and exploitation.

Resolving patch:
diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
--- a/mesonbuild/environment.py
+++ b/mesonbuild/environment.py
@@ -86,6 +86,7 @@
     'ppc64',
     'riscv32',
     'riscv64',
+    's390x',
     'sparc',
     'sparc64',
     'x86',


Test patch:
Repository: mesonbuild/meson

Issue:
gtkdoc-scangobj fails to find the shared library it scans (W32)
For example:
`Error in gtkdoc helper script:`
`'mingw\\bin\\python.EXE' failed with status 3221225781`
`WARNING:root:Running scanner failed: -1073741515, command: ./gtk4-scan.exe`
This is because the shared library being scanned is not in library search path. On *nix that is handled by adjusting `LD_LIBRARY_PATH`, but on W32 the variable that needs adjustment is `PATH`, and meson doesn't change it.

Here's a patch to fix that.
[0001-gtk-doc-Use-LD_LIBRARY_PATH-to-modify-PATH-on-W32.patch.txt](https://github.com/mesonbuild/meson/files/1843401/0001-gtk-doc-Use-LD_LIBRARY_PATH-to-modify-PATH-on-W32.patch.txt)



Discussion:
Please file a MR with that instead.
I can confirm that his fixes the docs build for pango

Resolving patch:
diff --git a/mesonbuild/scripts/gtkdochelper.py b/mesonbuild/scripts/gtkdochelper.py
--- a/mesonbuild/scripts/gtkdochelper.py
+++ b/mesonbuild/scripts/gtkdochelper.py
@@ -17,7 +17,7 @@
 import shlex
 import shutil
 import argparse
-from ..mesonlib import MesonException, Popen_safe
+from ..mesonlib import MesonException, Popen_safe, is_windows
 from . import destdir_join
 
 parser = argparse.ArgumentParser()
@@ -47,10 +47,20 @@
 parser.add_argument('--installdir', dest='install_dir')
 parser.add_argument('--run', dest='run', default='')
 
-def gtkdoc_run_check(cmd, cwd, library_path=None):
+def gtkdoc_run_check(cmd, cwd, library_paths=None):
+    if library_paths is None:
+        library_paths = []
+
     env = dict(os.environ)
-    if library_path:
-        env['LD_LIBRARY_PATH'] = library_path
+    if is_windows():
+        if 'PATH' in env:
+            library_paths.extend(env['PATH'].split(os.pathsep))
+        env['PATH'] = os.pathsep.join(library_paths)
+    else:
+        if 'LD_LIBRARY_PATH' in env:
+            library_paths.extend(env['LD_LIBRARY_PATH'].split(os.pathsep))
+        env['LD_LIBRARY_PATH'] = os.pathsep.join(library_paths)
+
     # Put stderr into stdout since we want to print it out anyway.
     # This preserves the order of messages.
     p, out = Popen_safe(cmd, cwd=cwd, env=env, stderr=subprocess.STDOUT)[0:2]
@@ -137,11 +147,8 @@ def build_gtkdoc(source_root, build_root, doc_subdir, src_subdirs,
         for ldflag in shlex.split(ldflags):
             if ldflag.startswith('-Wl,-rpath,'):
                 library_paths.append(ldflag[11:])
-        if 'LD_LIBRARY_PATH' in os.environ:
-            library_paths.append(os.environ['LD_LIBRARY_PATH'])
-        library_path = ':'.join(library_paths)
 
-        gtkdoc_run_check(scanobjs_cmd, build_root, library_path)
+        gtkdoc_run_check(scanobjs_cmd, build_root, library_paths)
 
     # Make docbook files
     if mode == 'auto':


Test patch:
Repository: mesonbuild/meson

Issue:
`meson install` broken with Windows MSI installer
After having installed meson via the MSI installer, I get this when trying to run `meson install` (or `ninja install`):
```
F:\projects\mesontest\libfoo\buildwin>meson install
Traceback (most recent call last):
  File "C:\python\lib\site-packages\cx_Freeze\initscripts\__startup__.py", line 14, in run
  File "C:\python\lib\site-packages\cx_Freeze\initscripts\Console.py", line 26, in run
  File "meson.py", line 29, in <module>
  File "mesonbuild\mesonmain.py", line 379, in main
  File "mesonbuild\mesonmain.py", line 283, in run
  File "mesonbuild\minstall.py", line 23, in <module>
ImportError: cannot import name '__file__'
```
- the problem exists with `meson-0.47.1-32.msi`, also with `meson-0.47.0-32.msi`
- works correctly with `meson-0.46.1-32.msi`
- also works correctly when installing python and getting meson 0.47.1 via `pip3 install meson`



Discussion:

Resolving patch:
diff --git a/mesonbuild/minstall.py b/mesonbuild/minstall.py
--- a/mesonbuild/minstall.py
+++ b/mesonbuild/minstall.py
@@ -20,7 +20,12 @@
 from .scripts import destdir_join
 from .mesonlib import is_windows, Popen_safe
 from .mtest import rebuild_all
-from __main__ import __file__ as main_file
+try:
+    from __main__ import __file__ as main_file
+except ImportError:
+    # Happens when running as meson.exe which is native Windows.
+    # This is only used for pkexec which is not, so this is fine.
+    main_file = None
 
 selinux_updates = []
 


Test patch: