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

Issue:
vala: AttributeError: 'RawFilename' object has no attribute 'endswith'
``` python
Traceback (most recent call last):
  File "/usr/share/meson/meson.py", line 188, in run
    app.generate()
  File "/usr/share/meson/meson.py", line 141, in generate
    g.generate()
  File "/usr/share/meson/ninjabackend.py", line 132, in generate
    [self.generate_target(t, outfile) for t in self.build.get_targets().values()]
  File "/usr/share/meson/ninjabackend.py", line 132, in <listcomp>
    [self.generate_target(t, outfile) for t in self.build.get_targets().values()]
  File "/usr/share/meson/ninjabackend.py", line 209, in generate_target
    header_deps))
  File "/usr/share/meson/ninjabackend.py", line 1100, in generate_single_compile
    compiler = self.get_compiler_for_source(src)
  File "/usr/share/meson/backends.py", line 54, in get_compiler_for_source
    if i.can_compile(src):
  File "/usr/share/meson/compilers.py", line 824, in can_compile
    return fname.endswith('.vala') or fname.endswith('.vapi')
AttributeError: 'RawFilename' object has no attribute 'endswith'
```



Discussion:

Resolving patch:
diff --git a/compilers.py b/compilers.py
--- a/compilers.py
+++ b/compilers.py
@@ -837,8 +837,9 @@ def sanity_check(self, work_dir):
         if pc.returncode != 0:
             raise EnvironmentException('Vala compiler %s can not compile programs.' % self.name_string())
 
-    def can_compile(self, fname):
-        return fname.endswith('.vala') or fname.endswith('.vapi')
+    def can_compile(self, filename):
+        suffix = filename.split('.')[-1]
+        return suffix in ('vala', 'vapi')
 
 class RustCompiler():
     def __init__(self, exelist, version):


Test patch:
Repository: mesonbuild/meson

Issue:
Allow passing extra arguments to gtkdoc-fixxref
Extra arguments are typically used to let `gtkdoc-fixxref` fix the cross referenced symbols in the API reference being built with the symbols exported by installed API references.

Having a `fixxref_args` similar to the existing `scan_args` and `html_args` would be enough to cover this use case.



Discussion:

Resolving patch:
diff --git a/mesonbuild/modules/gnome.py b/mesonbuild/modules/gnome.py
--- a/mesonbuild/modules/gnome.py
+++ b/mesonbuild/modules/gnome.py
@@ -289,6 +289,7 @@ def gtkdoc(self, state, args, kwargs):
                 '--modulename=' + modulename]
         args += self.unpack_args('--htmlargs=', 'html_args', kwargs)
         args += self.unpack_args('--scanargs=', 'scan_args', kwargs)
+        args += self.unpack_args('--fixxrefargs=', 'fixxref_args', kwargs)
         res = [build.RunTarget(targetname, command[0], command[1:] + args, state.subdir)]
         if kwargs.get('install', True):
             res.append(build.InstallScript(command + args))
diff --git a/mesonbuild/scripts/gtkdochelper.py b/mesonbuild/scripts/gtkdochelper.py
--- a/mesonbuild/scripts/gtkdochelper.py
+++ b/mesonbuild/scripts/gtkdochelper.py
@@ -28,9 +28,10 @@
 parser.add_argument('--modulename', dest='modulename')
 parser.add_argument('--htmlargs', dest='htmlargs', default='')
 parser.add_argument('--scanargs', dest='scanargs', default='')
+parser.add_argument('--fixxrefargs', dest='fixxrefargs', default='')
 
 def build_gtkdoc(source_root, build_root, doc_subdir, src_subdir,
-                 main_file, module, html_args, scan_args):
+                 main_file, module, html_args, scan_args, fixxref_args):
     abs_src = os.path.join(source_root, src_subdir)
     abs_out = os.path.join(build_root, doc_subdir)
     htmldir = os.path.join(abs_out, 'html')
@@ -76,7 +77,7 @@ def build_gtkdoc(source_root, build_root, doc_subdir, src_subdir,
     subprocess.check_call(mkhtml_cmd, cwd=os.path.join(abs_out, 'html'), shell=False)
     fixref_cmd = ['gtkdoc-fixxref',
                   '--module=' + module,
-                  '--module-dir=html']
+                  '--module-dir=html'] + fixxref_args
 #    print(fixref_cmd)
 #    sys.exit(1)
     subprocess.check_call(fixref_cmd, cwd=abs_out)
@@ -97,6 +98,10 @@ def run(args):
         scanargs = options.scanargs.split('@@')
     else:
         scanargs = []
+    if len(options.fixxrefargs) > 0:
+        fixxrefargs = options.fixxrefargs.split('@@')
+    else:
+        fixxrefargs = []
     build_gtkdoc(options.sourcedir,
                  options.builddir,
                  options.subdir,
@@ -104,7 +109,8 @@ def run(args):
                  options.mainfile,
                  options.modulename,
                  htmlargs,
-                 scanargs)
+                 scanargs,
+                 fixxrefargs)
 
     if 'MESON_INSTALL_PREFIX' in os.environ:
         if 'DESTDIR' in os.environ:


Test patch:
Repository: mesonbuild/meson

Issue:
Ensure PKG_CONFIG_PATH persistence
Encountered the following issue:

```
$ PKG_CONFIG_PATH=/foo/pkgconfig meson
```

and everything builds fine, _but_ one of the meson.build files has something like this:

```
runcmd = run_command('pkg-config', '--variable=pluginsdir', 'gstreamer-1.0')
```

The problem is now that without an export the environment passed to meson is not inherited by subprocesses (I think that's the issue anyway, although I'm not sure why the dependency() detection via pkg-config works then, since it's also a subprocess), so it returns the pluginsdir of the installed gstreamer here, not the prefix I specified.

I think it's unreasonable to expect users to export this var, so I think whatever the issue is it needs to be worked around in meson somehow or we need specific functions to do the equivalent that will do the right thing.



Discussion:
Hrm, I must be confused. Can't reproduce this now with a clean build. No idea why it picked up the other path yesterday then.

This happened because I modified a meson.build file, and meson got automatically re-run when I ran `ninja`. At that point `PKG_CONFIG_PATH` is no longer set though, so the above run_command() yields a different/wrong result.


Resolving patch:
diff --git a/mesonbuild/coredata.py b/mesonbuild/coredata.py
--- a/mesonbuild/coredata.py
+++ b/mesonbuild/coredata.py
@@ -133,6 +133,8 @@ def __init__(self, options):
         self.cross_compilers = {}
         self.deps = {}
         self.modules = {}
+        # Only to print a warning if it changes between Meson invocations.
+        self.pkgconf_envvar = os.environ.get('PKG_CONFIG_PATH', '')
 
     def init_builtins(self, options):
         self.builtins = {}
diff --git a/mesonbuild/mesonmain.py b/mesonbuild/mesonmain.py
--- a/mesonbuild/mesonmain.py
+++ b/mesonbuild/mesonmain.py
@@ -117,6 +117,13 @@ def validate_dirs(self, dir1, dir2, handshake):
                 raise RuntimeError('Something went terribly wrong. Please file a bug.')
         return (src_dir, build_dir)
 
+    def check_pkgconfig_envvar(self, env):
+        curvar = os.environ.get('PKG_CONFIG_PATH', '')
+        if curvar != env.coredata.pkgconf_envvar:
+            mlog.log(mlog.red("WARNING:"), 'PKG_CONFIG_PATH has changed between invocations from "%s" to "%s".' %
+                     (env.coredata.pkgconf_envvar, curvar))
+            env.coredata.pkgconf_envvar = curvar
+
     def generate(self):
         env = environment.Environment(self.source_dir, self.build_dir, self.meson_script_file, self.options, self.original_cmd_line_args)
         mlog.initialize(env.get_log_dir())
@@ -124,6 +131,7 @@ def generate(self):
         mlog.debug('Python binary:', sys.executable)
         mlog.debug('Python system:', platform.system())
         mlog.log(mlog.bold('The Meson build system'))
+        self.check_pkgconfig_envvar(env)
         mlog.log('Version:', coredata.version)
         mlog.log('Source dir:', mlog.bold(self.source_dir))
         mlog.log('Build dir:', mlog.bold(self.build_dir))


Test patch:
Repository: mesonbuild/meson

Issue:
Error message 'Subproject directory does not exist and can not be downloaded.'
So I was a bit stupid and didn't read the documentation properly and I added a folder `submodules` to my source tree. It would be nice if Meson would check for the `subprojects` folder first, and if the error message would say instead: 'Directory "subprojects" not found in folder "..."'.



Discussion:

Resolving patch:
diff --git a/mesonbuild/interpreter.py b/mesonbuild/interpreter.py
--- a/mesonbuild/interpreter.py
+++ b/mesonbuild/interpreter.py
@@ -1387,7 +1387,8 @@ def do_subproject(self, dirname, kwargs):
         r = wrap.Resolver(os.path.join(self.build.environment.get_source_dir(), self.subproject_dir))
         resolved = r.resolve(dirname)
         if resolved is None:
-            raise InterpreterException('Subproject directory does not exist and can not be downloaded.')
+            msg = 'Subproject directory {!r} does not exist and can not be downloaded.'
+            raise InterpreterException(msg.format(os.path.join(self.subproject_dir, dirname)))
         subdir = os.path.join(self.subproject_dir, resolved)
         os.makedirs(os.path.join(self.build.environment.get_build_dir(), subdir), exist_ok=True)
         self.global_args_frozen = True


Test patch:
Repository: mesonbuild/meson

Issue:
shared_library() kwarg vs_module_defs should trigger rebuild
When the visual studio module definitions file is edited, the library that uses it should get re-linked.



Discussion:
So it should just set up link_depends properly behind the scenes? [Example](https://github.com/mesonbuild/meson/blob/master/test%20cases/linuxlike/3%20linker%20script/meson.build).

Oh, right. I forgot that it's available via that too.


Resolving patch:
diff --git a/mesonbuild/build.py b/mesonbuild/build.py
--- a/mesonbuild/build.py
+++ b/mesonbuild/build.py
@@ -876,6 +876,8 @@ def process_kwargs(self, kwargs, environment):
                 self.vs_module_defs = File.from_absolute_file(path)
             else:
                 self.vs_module_defs = File.from_source_file(environment.source_dir, self.subdir, path)
+            # link_depends can be an absolute path or relative to self.subdir
+            self.link_depends.append(path)
 
     def check_unknown_kwargs(self, kwargs):
         self.check_unknown_kwargs_int(kwargs, known_shlib_kwargs)


Test patch:
Repository: mesonbuild/meson

Issue:
fPIC flag is on for MSYS2/Cygwin
MSYS2 and Cygwin are Unix-like environments that run on Windows. This means that meson presumably assumes it is running under a Unix and turns on the -fPIC flag for C(++) shared libraries. However, since it is actually a windows system, a warning about the flag is generated.



Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers.py b/mesonbuild/compilers.py
--- a/mesonbuild/compilers.py
+++ b/mesonbuild/compilers.py
@@ -1869,6 +1869,11 @@ def get_colorout_args(self, colortype):
             return gnu_color_args[colortype][:]
         return []
 
+    def get_pic_args(self):
+        if self.gcc_type == GCC_MINGW:
+            return [] # On Window gcc defaults to fpic being always on.
+        return ['-fPIC']
+
     def get_always_args(self):
         return ['-pipe']
 


Test patch:
Repository: mesonbuild/meson

Issue:
Several GNU directory options are not available
I see several [predefined directory options](https://github.com/mesonbuild/meson/blob/master/mesonbuild/coredata.py#L202), but several of the [GNU Coding Standard directories](https://www.gnu.org/prep/standards/html_node/Directory-Variables.html) are missing, notably `sysconfdir` being the main one.



Discussion:
We have not added all of them because we don't really know which ones are actually used and which ones are legacy. If you list which ones your project need, we can add those.

For the moment, I think only `sysconfdir` is the missing one.


Resolving patch:
diff --git a/mesonbuild/coredata.py b/mesonbuild/coredata.py
--- a/mesonbuild/coredata.py
+++ b/mesonbuild/coredata.py
@@ -211,6 +211,7 @@ def get_builtin_option_default(optname):
         'datadir'           : [ UserStringOption, 'Data file directory.', 'share' ],
         'mandir'            : [ UserStringOption, 'Manual page directory.', 'share/man' ],
         'localedir'         : [ UserStringOption, 'Locale data directory.', 'share/locale' ],
+        'sysconfdir'        : [ UserStringOption, 'Sysconf data directory.', '/etc' ],
         'werror'            : [ UserBooleanOption, 'Treat warnings as errors.', False ],
         'warning_level'     : [ UserComboOption, 'Compiler warning level to use.', [ '1', '2', '3' ], '1'],
         'layout'            : [ UserComboOption, 'Build directory layout.', ['mirror', 'flat' ], 'mirror' ],
diff --git a/mesonbuild/mesonmain.py b/mesonbuild/mesonmain.py
--- a/mesonbuild/mesonmain.py
+++ b/mesonbuild/mesonmain.py
@@ -47,6 +47,7 @@ def add_builtin_argument(name, **kwargs):
 add_builtin_argument('datadir')
 add_builtin_argument('mandir')
 add_builtin_argument('localedir')
+add_builtin_argument('sysconfdir')
 add_builtin_argument('backend')
 add_builtin_argument('buildtype')
 add_builtin_argument('strip', action='store_true')


Test patch:
diff --git a/test cases/common/12 data/meson.build b/test cases/common/12 data/meson.build
--- a/test cases/common/12 data/meson.build	
+++ b/test cases/common/12 data/meson.build	
@@ -1,6 +1,6 @@
 project('data install test', 'c')
 install_data(sources : 'datafile.dat', install_dir : 'share/progname')
-install_data(sources : 'etcfile.dat', install_dir : '/etc')
+install_data(sources : 'etcfile.dat', install_dir : get_option('sysconfdir'))
 
 subdir('vanishing')
Repository: mesonbuild/meson

Issue:
Several GNU directory options are not available
I see several [predefined directory options](https://github.com/mesonbuild/meson/blob/master/mesonbuild/coredata.py#L202), but several of the [GNU Coding Standard directories](https://www.gnu.org/prep/standards/html_node/Directory-Variables.html) are missing, notably `sysconfdir` being the main one.



Discussion:
We have not added all of them because we don't really know which ones are actually used and which ones are legacy. If you list which ones your project need, we can add those.

For the moment, I think only `sysconfdir` is the missing one.


Resolving patch:
diff --git a/mesonbuild/coredata.py b/mesonbuild/coredata.py
--- a/mesonbuild/coredata.py
+++ b/mesonbuild/coredata.py
@@ -211,6 +211,11 @@ def get_builtin_option_default(optname):
         'datadir'           : [ UserStringOption, 'Data file directory.', 'share' ],
         'mandir'            : [ UserStringOption, 'Manual page directory.', 'share/man' ],
         'localedir'         : [ UserStringOption, 'Locale data directory.', 'share/locale' ],
+    # Sysconfdir is a bit special. It defaults to ${prefix}/etc but nobody
+    # uses that. Instead they always set it manually to /etc. This default
+    # value is thus pointless and not really used but we set it to this
+    # for consistency with other systems.
+        'sysconfdir'        : [ UserStringOption, 'Sysconf data directory.', 'etc' ],
         'werror'            : [ UserBooleanOption, 'Treat warnings as errors.', False ],
         'warning_level'     : [ UserComboOption, 'Compiler warning level to use.', [ '1', '2', '3' ], '1'],
         'layout'            : [ UserComboOption, 'Build directory layout.', ['mirror', 'flat' ], 'mirror' ],
diff --git a/mesonbuild/mesonmain.py b/mesonbuild/mesonmain.py
--- a/mesonbuild/mesonmain.py
+++ b/mesonbuild/mesonmain.py
@@ -47,6 +47,7 @@ def add_builtin_argument(name, **kwargs):
 add_builtin_argument('datadir')
 add_builtin_argument('mandir')
 add_builtin_argument('localedir')
+add_builtin_argument('sysconfdir')
 add_builtin_argument('backend')
 add_builtin_argument('buildtype')
 add_builtin_argument('strip', action='store_true')


Test patch:
Repository: mesonbuild/meson

Issue:
compiler.has_argument doesn't work with clang for warnings
Try this meson.build (github wouldn't let me upload directly here) https://gist.github.com/iainlane/2935fba6bdd02214eb2de4212573aa3b with `CC=gcc` and then `CC=clang`. The option is unknown, and yet the test passes with clang.

In `meson-log.txt` we can see why:

```
Running compile:
Command line:  clang /tmp/tmph4afoz0x.c -Wzzzzzzzz -c·

Code:
 int i;

Compiler stdout:
 warning: unknown warning option '-Wzzzzzzzz' [-Wunknown-warning-option]
1 warning generated.

Compiler stderr:
·
Compiler for c supports argument -Wzzzzzzzz: YES

Meson encountered an error in file meson.build, line 6, column 8:
Error encountered: buggy
```

clang is only outputting this as a warning. There's a clang-specific flag `-Werror=unknown-warning-option`, which meson could pass. It's clang-specific because it makes gcc error. Or meson could pass `-Werror` for `has_argument`, which I hope works for all compilers, but maybe it's less safe to do so for `has_argument` for some reason I haven't thought of yet - like a value a user could pass that generates a warning but is actually okay (deprecations?).



Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers.py b/mesonbuild/compilers.py
--- a/mesonbuild/compilers.py
+++ b/mesonbuild/compilers.py
@@ -2126,6 +2126,9 @@ def get_option_compile_args(self, options):
     def get_option_link_args(self, options):
         return []
 
+    def has_argument(self, arg, env):
+        return super().has_argument(['-Werror=unknown-warning-option', arg], env)
+
 class GnuCPPCompiler(CPPCompiler):
     # may need to separate the latter to extra_debug_args or something
     std_debug_args = ['-g']
@@ -2240,6 +2243,9 @@ def get_option_compile_args(self, options):
     def get_option_link_args(self, options):
         return []
 
+    def has_argument(self, arg, env):
+        return super().has_argument(['-Werror=unknown-warning-option', arg], env)
+
 class FortranCompiler(Compiler):
     def __init__(self, exelist, version, is_cross, exe_wrapper=None):
         super().__init__(exelist, version)


Test patch:
diff --git a/test cases/common/103 manygen/subdir/manygen.py b/test cases/common/103 manygen/subdir/manygen.py
--- a/test cases/common/103 manygen/subdir/manygen.py	
+++ b/test cases/common/103 manygen/subdir/manygen.py	
@@ -22,7 +22,8 @@
         shutil.which('clang') or \
         shutil.which('cc')
 
-if 'cl' in os.path.basename(compiler):
+compbase = os.path.basename(compiler)
+if 'cl' in compbase and 'clang' not in compbase:
     libsuffix = '.lib'
     is_vs = True
     compiler = 'cl'
Repository: mesonbuild/meson

Issue:
Refix gst building
MR #737 broke building of gst. This is a regression. Unless we can come up with a fix to make both work, the MR should be reverted.



Discussion:

Resolving patch:
diff --git a/mesonbuild/backend/backends.py b/mesonbuild/backend/backends.py
--- a/mesonbuild/backend/backends.py
+++ b/mesonbuild/backend/backends.py
@@ -599,6 +599,25 @@ def eval_custom_target_command(self, target, absolute_paths=False):
                                   os.path.join(lead_dir,
                                                outdir))
                 cmd.append(i)
+        # This should not be necessary but removing it breaks
+        # building GStreamer on Windows. The underlying issue
+        # is problems with quoting backslashes on Windows
+        # which is the seventh circle of hell. The downside is
+        # that this breaks custom targets whose command lines
+        # have backslashes. If you try to fix this be sure to
+        # check that it does not break GST.
+        #
+        # The bug causes file paths such as c:\foo to get escaped
+        # into c:\\foo.
+        #
+        # Unfortunately we have not been able to come up with an
+        # isolated test case for this so unless you manage to come up
+        # with one, the only way is to test the building with Gst's
+        # setup. Note this in your MR or ping us and we will get it
+        # fixed.
+        #
+        # https://github.com/mesonbuild/meson/pull/737
+        cmd = [i.replace('\\', '/') for i in cmd]
         return (srcs, ofilenames, cmd)
 
     def run_postconf_scripts(self):


Test patch:
Repository: mesonbuild/meson

Issue:
i18n: gettextname-pot target requires po/POTFILES in source directory
In an autotools setup you usually have `po/POTFILES.in` from which `po/POTFILES` is created at configure time. Why I'm not sure, I've never seen anything in a POTFILES.in that looked like it would be substituted. Maybe it's for the timestamp, who knows.

In any case, `ninja gettextname-pot` currently has `po/POTFILES` hard-coded and looks for it in the source directory. That is suboptimal for projects who want to have meson and autotools build in parallel.

Possible solutions:
- add option to `i18n.gettext()` to pass the name of the `POTFILES` files (then we could just use the `POTFILES.in` from the source dir; optionally support a configure_file() too
- look for `$topsrcdir/po/POTFILES.in` automatically if `$topsrcdir/po/POTFILES` does not exist.
- anything else?



Discussion:
I wondered about this when writing the gettext module, too. Timestamp is the probable answer but now that we have reproducible builds timestamps of any kind are very much frowned upon.

Does gettext work if it is given `POTFILES.in` instead of `POTFILES`? Checking which one of these exists and then using it seems like the simplest thing to do.


Resolving patch:
diff --git a/mesonbuild/scripts/gettext.py b/mesonbuild/scripts/gettext.py
--- a/mesonbuild/scripts/gettext.py
+++ b/mesonbuild/scripts/gettext.py
@@ -19,6 +19,12 @@
 
 def run_potgen(src_sub, pkgname, args):
     listfile = os.path.join(src_sub, 'POTFILES')
+    if not os.path.exists(listfile):
+        listfile = os.path.join(src_sub, 'POTFILES.in')
+        if not os.path.exists(listfile):
+            print('Could not find file POTFILES in %s' % src_sub)
+            return 1
+
     ofile = os.path.join(src_sub, pkgname + '.pot')
     return subprocess.call(['xgettext', '--package-name=' + pkgname, '-p', src_sub, '-f', listfile,
                             '-D', os.environ['MESON_SOURCE_ROOT'], '-k_', '-o', ofile] + args)


Test patch:
Repository: mesonbuild/meson

Issue:
python string encoding woes
The crux of the matter is (with print debugging):
'ascii' codec can't decode byte 0xc3 in position 91: ordinal not in range(128)

Meson encountered an error in file subprojects/gst-plugins-base/gst-libs/gst/pbutils/meson.build, line 20, column 0:
Could not read input file /home/matt/Projects/gst/gst-all/subprojects/gst-plugins-base/gst-libs/gst/pbutils/gstpluginsbaseversion.h.in.

The 91st character in that file is a ü.

The only difference between this build and all my previous builds is that I'm attempting to build over an ssh connection here.

I've worked around it for now by using codecs.open(, 'utf-8') instead of plain open() but this still begs the question, what are we going to do about this (and any other string encoding issue)?

We can replace all the instances of open() with codecs.open() which should cover the majority of use cases however there are probably some files that won't work with a utf-8 encoding.



Discussion:
I think I should agree to do `open()` -> `codecs.open(..., 'utf-8')`


Resolving patch:
diff --git a/mesonbuild/mesonlib.py b/mesonbuild/mesonlib.py
--- a/mesonbuild/mesonlib.py
+++ b/mesonbuild/mesonlib.py
@@ -255,10 +255,10 @@ def do_mesondefine(line, confdata):
 
 def do_conf_file(src, dst, confdata):
     try:
-        with open(src) as f:
+        with open(src, encoding='utf-8') as f:
             data = f.readlines()
-    except Exception:
-        raise MesonException('Could not read input file %s.' % src)
+    except Exception as e:
+        raise MesonException('Could not read input file %s: %s' % (src, str(e)))
     # Only allow (a-z, A-Z, 0-9, _, -) as valid characters for a define
     # Also allow escaping '@' with '\@'
     regex = re.compile(r'[^\\]?@([-a-zA-Z0-9_]+)@')


Test patch: