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

Issue:
Cannot create shared libraries from D sources on OSX (and macOS)
Using the `library` function in a 'meson.build' to create a shared library on Debian Sid and Fedora Rawhide works fine. For example:
```
tinyendian_lib = library(
    meson.project_name(),
    [tinyendian_src],
    include_directories: [src_dir],
    version: meson.project_version(),
    pic: true,
    install: true,
)
```
correctly builds the '.so' file and it all installs fine. However on OSX (I am on El Capitan) and I assume macOS, the option `-L-soname` is passed to the 'ldc2' command line, and whilst this works for Linux, it does not work for OSX:
```
  FAILED: libtinyendian.0.dylib 
ldc2  -of libtinyendian.0.dylib 'tinyendian@sha/source_tinyendian.d.o' -shared -relocation-model=pic -L-soname -Llibtinyendian.dylib.0  
ld: unknown option: -soname
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error: /usr/bin/gcc failed with status: 1
```
I believe this to be an error in the D tooling for Meson.


Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers/d.py b/mesonbuild/compilers/d.py
--- a/mesonbuild/compilers/d.py
+++ b/mesonbuild/compilers/d.py
@@ -14,10 +14,12 @@
 
 import os.path, subprocess
 
-from ..mesonlib import EnvironmentException, version_compare
+from ..mesonlib import EnvironmentException, version_compare, is_windows, is_osx
 
 from .compilers import (
     GCC_STANDARD,
+    GCC_CYGWIN,
+    GCC_OSX,
     d_dmd_buildtype_args,
     d_gdc_buildtype_args,
     d_ldc_buildtype_args,
@@ -90,8 +92,15 @@ def get_std_shared_lib_link_args(self):
         return ['-shared']
 
     def get_soname_args(self, prefix, shlib_name, suffix, soversion, is_shared_module):
-        # FIXME: Make this work for Windows, MacOS and cross-compiling
-        return get_gcc_soname_args(GCC_STANDARD, prefix, shlib_name, suffix, soversion, is_shared_module)
+        # FIXME: Make this work for cross-compiling
+        gcc_type = GCC_STANDARD
+        if is_windows():
+            gcc_type = GCC_CYGWIN
+        if is_osx():
+            gcc_type = GCC_OSX
+
+        return get_gcc_soname_args(gcc_type, prefix, shlib_name, suffix, soversion, is_shared_module)
+
 
     def get_feature_args(self, kwargs, build_to_src):
         res = []
@@ -212,6 +221,9 @@ def translate_args_to_nongnu(cls, args):
                 for la in linkargs:
                     dcargs.append('-L' + la.strip())
                 continue
+            elif arg.startswith('-install-name'):
+                dcargs.append('-L' + arg)
+                continue
             elif arg.startswith('-link-defaultlib') or arg.startswith('-linker'):
                 # these are special arguments to the LDC linker call,
                 # arguments like "-link-defaultlib-shared" do *not*


Test patch:
Repository: mesonbuild/meson

Issue:
Question: "Python module" vs "Python 3 module"
From the documentation, I can't tell when I should use the "Python module" (which supports both Python 2 and Python 3) vs. the "Python 3 module". It looks like the "Python module" is much newer. They both have very similar methods and descriptions.

Is the "Python 3" module deprecated? If so, should it be removed in favor of the more generic "Python module"?

Links to the relevant documentation here:
https://mesonbuild.com/Python-module.html
https://mesonbuild.com/Python-3-module.html


Discussion:
I was wondering the same recently, I think python3 module should be deprecated, but I'm not sure. @MathieuDuponchelle do you know if your module replace the previous one?
@xclaesse yes, the previous module should IMHO be deprecated, I did not however want to make that a part of the discussion regarding the newer one :)

Resolving patch:
diff --git a/mesonbuild/modules/python3.py b/mesonbuild/modules/python3.py
--- a/mesonbuild/modules/python3.py
+++ b/mesonbuild/modules/python3.py
@@ -17,11 +17,12 @@
 
 from . import ExtensionModule
 from mesonbuild.modules import ModuleReturnValue
-from ..interpreterbase import noKwargs, permittedKwargs
+from ..interpreterbase import noKwargs, permittedKwargs, FeatureDeprecated
 from ..build import known_shmod_kwargs
 
 
 class Python3Module(ExtensionModule):
+    @FeatureDeprecated('python3 module', '0.48.0')
     def __init__(self, *args, **kwargs):
         super().__init__(*args, **kwargs)
         self.snippets.add('extension_module')


Test patch:
Repository: mesonbuild/meson

Issue:
Add support for ui_extra_arguments to qt5
Just like https://github.com/mesonbuild/meson/pull/2529 adds moc_extra_arguments, ui_extra_arguments would be useful to override translator function (hello gettext/i18n).


Discussion:

Resolving patch:
diff --git a/mesonbuild/modules/qt.py b/mesonbuild/modules/qt.py
--- a/mesonbuild/modules/qt.py
+++ b/mesonbuild/modules/qt.py
@@ -116,11 +116,12 @@ def parse_qrc(self, state, rcc_file):
         except Exception:
             return []
 
+    @FeatureNewKwargs('qt.preprocess', '0.49.0', ['uic_extra_arguments'])
     @FeatureNewKwargs('qt.preprocess', '0.44.0', ['moc_extra_arguments'])
-    @permittedKwargs({'moc_headers', 'moc_sources', 'moc_extra_arguments', 'include_directories', 'dependencies', 'ui_files', 'qresources', 'method'})
+    @permittedKwargs({'moc_headers', 'moc_sources', 'uic_extra_arguments', 'moc_extra_arguments', 'include_directories', 'dependencies', 'ui_files', 'qresources', 'method'})
     def preprocess(self, state, args, kwargs):
-        rcc_files, ui_files, moc_headers, moc_sources, moc_extra_arguments, sources, include_directories, dependencies \
-            = extract_as_list(kwargs, 'qresources', 'ui_files', 'moc_headers', 'moc_sources', 'moc_extra_arguments', 'sources', 'include_directories', 'dependencies', pop = True)
+        rcc_files, ui_files, moc_headers, moc_sources, uic_extra_arguments, moc_extra_arguments, sources, include_directories, dependencies \
+            = extract_as_list(kwargs, 'qresources', 'ui_files', 'moc_headers', 'moc_sources', 'uic_extra_arguments', 'moc_extra_arguments', 'sources', 'include_directories', 'dependencies', pop = True)
         sources += args[1:]
         method = kwargs.get('method', 'auto')
         self._detect_tools(state.environment, method)
@@ -160,8 +161,9 @@ def preprocess(self, state, args, kwargs):
         if len(ui_files) > 0:
             if not self.uic.found():
                 raise MesonException(err_msg.format('UIC', 'uic-qt' + self.qt_version))
+            arguments = uic_extra_arguments + ['-o', '@OUTPUT@', '@INPUT@']
             ui_kwargs = {'output': 'ui_@BASENAME@.h',
-                         'arguments': ['-o', '@OUTPUT@', '@INPUT@']}
+                         'arguments': arguments}
             ui_gen = build.Generator([self.uic], ui_kwargs)
             ui_output = ui_gen.process_files('Qt{} ui'.format(self.qt_version), ui_files, state)
             sources.append(ui_output)


Test patch:
Repository: mesonbuild/meson

Issue:
Gdbus unit tests do not pass on 0.48 rc
```
======================================================================
FAIL: test_introspect_dependencies (__main__.LinuxlikeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./run_unittests.py", line 3797, in test_introspect_dependencies
    self.assertEqual(t['filename'], 'gdbus/generated-gdbus-doc-' + ifile)
AssertionError: 'gdbus/generated-gdbus-doc-com.example.Sample.xml' != 'gdbus/generated-gdbus-doc-gdbus/data/com.example.Sample.xml'
- gdbus/generated-gdbus-doc-com.example.Sample.xml
+ gdbus/generated-gdbus-doc-gdbus/data/com.example.Sample.xml
?                           +++++++++++
```

This is a release blocker.


Discussion:
Bisect says that the error appeared in commit 43f7a750, which is by @nirbheek.
This does not show up in CI probably due to the fact that this test requires a fairly new glib.

Resolving patch:
diff --git a/run_unittests.py b/run_unittests.py
--- a/run_unittests.py
+++ b/run_unittests.py
@@ -3794,7 +3794,7 @@ def test_introspect_dependencies(self):
                 break
         self.assertIsInstance(docbook_target, dict)
         ifile = self.introspect(['--target-files', 'generated-gdbus-docbook@cus'])[0]
-        self.assertEqual(t['filename'], 'gdbus/generated-gdbus-doc-' + ifile)
+        self.assertEqual(t['filename'], 'gdbus/generated-gdbus-doc-' + os.path.basename(ifile))
 
     def test_build_rpath(self):
         if is_cygwin():


Test patch:
Repository: mesonbuild/meson

Issue:
Meson fails with "Directory already configured." when it should ignore and continue recompiling.
In the past, Meson would just complain and then ignore, instead of failing, when attempting to setup a directory that was already setup.

The usecase here is when recompiling Mesa master with an Arch PKGBUILD which builds against precompiled and installed LLVM master packages which are updated every 6 hours. I prefer to avoid compiled Mesa from scratch everytime.

Previously, it would just recompile the relevant files, on average 100. But, now, I would be forced to wait for all 2250 or so files to be compiled from scratch.

If I add `|| true` to the end of `meson setup`, nothing gets recompiled. If I remove `build/meson-private/coredata.dat`, at least 450 files get recompiled every time, without fail. Which is annoying.

Does Meson really have to fail with an error if the directory is already setup? Can it just not continue to issue a warning like before, and then just continue?


Discussion:
PKGBUILD I build with: https://paste.kde.org/pzvmuqojz
I should also have added that it last worked with 0.47.2, but is failing with 0.48.0.
Oh, right `--reconfigure` exists... nevermind...
That's actually my fault in commit 674ae466c8f28008bf3576c5571095f98e046833, I changed an exit(0) to exit(1). I guess it makes sense to revert to exit(0).

Note that adding --reconfigure in your case will fail the build if the builddir does not exist yet.

Resolving patch:
diff --git a/mesonbuild/mesonmain.py b/mesonbuild/mesonmain.py
--- a/mesonbuild/mesonmain.py
+++ b/mesonbuild/mesonmain.py
@@ -113,7 +113,7 @@ def validate_dirs(self, dir1, dir2, reconfigure):
                       '\nIf build failures persist, manually wipe your build directory to clear any\n'
                       'stored system data.\n'
                       '\nTo change option values, run "meson configure" instead.')
-                sys.exit(1)
+                sys.exit(0)
         else:
             if reconfigure:
                 print('Directory does not contain a valid build tree:\n{}'.format(build_dir))


Test patch:
Repository: mesonbuild/meson

Issue:
regression: mesa x86_64 -> x86 compilation broken with meson 0.48
Commit 16fa65730469dacbdb9374858c090fe59c1aa70c adds code that checks that if a compiled file is used as a generator that it is either native to the build_machine or there is an exe wrapper. There are some cases where the build machine can run host machine binaries without an emulation layer, such as when building x86 code on an x86_64 machine of the same OS.


Discussion:
See also: https://bugs.gentoo.org/666968

Resolving patch:
diff --git a/mesonbuild/backend/backends.py b/mesonbuild/backend/backends.py
--- a/mesonbuild/backend/backends.py
+++ b/mesonbuild/backend/backends.py
@@ -13,6 +13,7 @@
 # limitations under the License.
 
 import os, pickle, re
+import textwrap
 from .. import build
 from .. import dependencies
 from .. import mesonlib
@@ -731,10 +732,11 @@ def get_regen_filelist(self):
     def exe_object_to_cmd_array(self, exe):
         if self.environment.is_cross_build() and \
            isinstance(exe, build.BuildTarget) and exe.is_cross:
-            if self.environment.exe_wrapper is None:
-                s = 'Can not use target %s as a generator because it is cross-built\n'
-                s += 'and no exe wrapper is defined. You might want to set it to native instead.'
-                s = s % exe.name
+            if self.environment.exe_wrapper is None and self.environment.cross_info.need_exe_wrapper():
+                s = textwrap.dedent('''
+                    Can not use target {} as a generator because it is cross-built
+                    and no exe wrapper is defined or needs_exe_wrapper is true.
+                    You might want to set it to native instead.'''.format(exe.name))
                 raise MesonException(s)
         if isinstance(exe, build.BuildTarget):
             exe_arr = [os.path.join(self.environment.get_build_dir(), self.get_target_filename(exe))]


Test patch:
Repository: mesonbuild/meson

Issue:
"ninja -C builddir test" fails on appveyor with 0.48.0
```
ninja -C builddir test
ninja: Entering directory `builddir'
[0/1] Running all tests.
usage: meson [-h]
             [--buildtype {plain,debug,debugoptimized,release,minsize,custom}]
             [--strip] [--unity {on,off,subprojects}] [--prefix PREFIX]
             [--libdir LIBDIR] [--libexecdir LIBEXECDIR] [--bindir BINDIR]
             [--sbindir SBINDIR] [--includedir INCLUDEDIR] [--datadir DATADIR]
             [--mandir MANDIR] [--infodir INFODIR] [--localedir LOCALEDIR]
             [--sysconfdir SYSCONFDIR] [--localstatedir LOCALSTATEDIR]
             [--sharedstatedir SHAREDSTATEDIR] [--werror]
             [--warnlevel {1,2,3}] [--layout {mirror,flat}]
             [--default-library {shared,static,both}]
             [--backend {ninja,vs,vs2010,vs2015,vs2017,xcode}] [--stdsplit]
             [--errorlogs] [--install-umask INSTALL_UMASK]
             [--auto-features {enabled,disabled,auto}]
             [--optimization {0,g,1,2,3,s}] [--debug] [-D option]
             [--cross-file CROSS_FILE] [-v]
             [--wrap-mode {default,nofallback,nodownload,forcefallback}]
             [--fatal-meson-warnings] [--reconfigure]
             [builddir] [sourcedir]
meson: error: unrecognized arguments: -u --no-rebuild --print-errorlogs
FAILED: meson-test 
"C:\\python37\\Scripts\\meson" "-u" "test" "--no-rebuild" "--print-errorlogs"
ninja: build stopped: subcommand failed.
Command exited with code 1
```
The same configuration worked in 0.47.2.

Full build log at https://ci.appveyor.com/project/z3ntu/razer-test/build/job/8ak33l51nayn4a92


Discussion:

Resolving patch:
diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
--- a/mesonbuild/environment.py
+++ b/mesonbuild/environment.py
@@ -375,7 +375,7 @@ def get_coredata(self):
 
     def get_build_command(self, unbuffered=False):
         cmd = mesonlib.meson_command[:]
-        if unbuffered and 'python' in cmd[0]:
+        if unbuffered and 'python' in os.path.basename(cmd[0]):
             cmd.insert(1, '-u')
         return cmd
 


Test patch:
Repository: mesonbuild/meson

Issue:
The llvm test fails if static llvm libraries are not provided
On Gentoo Linux at least, and maybe other distros, the static llvm libraries are not provided by default.
This means that the test suite fails because it is unable to statically link llvm.
The issue is in the following file:

test cases/frameworks/15 llvm/meson.build

In this file, the foreach loop  currently reads:

```
foreach static : [true, false]
```

We patch it like this to get passed the failure:

```
foreach static : [false]
```

I'm thinking we should dynamically generate this list based on what is on the system and use that to control the loop instead of hard coding the list.

Any thoughts?

@floppym 


Discussion:
CCing @dcbaker 
Yes, that seems to be the case still. Sigh, I thought I fixed this with the last patches.

Resolving patch:
diff --git a/mesonbuild/dependencies/dev.py b/mesonbuild/dependencies/dev.py
--- a/mesonbuild/dependencies/dev.py
+++ b/mesonbuild/dependencies/dev.py
@@ -310,6 +310,7 @@ def _set_new_link_args(self, environment):
                 if not matches:
                     if self.required:
                         raise
+                    self.is_found = False
                     return
 
                 self.link_args = self.get_config_value(['--ldflags'], 'link_args')
@@ -326,6 +327,8 @@ def _set_new_link_args(self, environment):
             except DependencyException:
                 if self.required:
                     raise
+                self.is_found = False
+                return
 
         link_args = ['--link-static', '--system-libs'] if self.static else ['--link-shared']
         self.link_args = self.get_config_value(


Test patch:
Repository: mesonbuild/meson

Issue:
Unknown CPU family 'powerpc'
I'm using meson to build a program.

I'm getting this warning:
`WARNING: Unknown CPU family 'powerpc', please report this at https://github.com/mesonbuild/meson/issues/new with theoutput of `uname -a` and `cat /proc/cpuinfo``

uname -a:
`FreeBSD XXX 12.0-BETA1 FreeBSD 12.0-BETA1 #7 r339445M: Sat Oct 20 02:36:21 CEST 2018     root@:/usr/obj/usr/src/powerpc.powerpc64/sys/GENERIC64  powerpc`

Since this is FreeBSD, there's no `/proc/cpuinfo`.

Excerpt from dmesg:
```
cpu0: IBM POWER9 revision 2.2, 2700.00 MHz
cpu0: Features dc007182<PPC32,PPC64,ALTIVEC,FPU,MMU,SMT,ISNOOP,ARCH205,ARCH206,VSX,TRUELE>
cpu0: Features2 eee00000<ARCH207,HTM,DSCR,ISEL,TAR,VCRYPTO,ARCH300,IEEE128,DARN>
```


Discussion:
Could you answer a few more questions so we can get the detection logic working [and documented](https://mesonbuild.com/Reference-tables.html#cpu-families) properly.

Is `powerpc` the same on FreeBSD as `ppc32/64` is on Linux?

Are there cases where FreeBSD returns `ppc32` as the architecture? As an example it might return `ppc` for old ppc chips and `powerpc` for newer ones?

Does FreeBSD always return `powerpc` as the architecture, both on 32 and 64 bit architectures? If yes, is there a way to tell which one we are currently using apart from checking the size of `void *`?
Yes, `powerpc` on FreeBSD can be either `ppc32` (then it's just `powerpc`) or `ppc64` (in that case it's often referred to as `powerpc64`, but can be just `powerpc` too, similar to people using `x86` and `x86_64` interchangeably).

No, FreeBSD doesn't use `ppc32` name.

Yes, FreeBSD always uses the `powerpc` name. To check whether it's 32 bit or 64 bit, you can check `uname -p`. Note that there's also a third subarchitecture - `powerpcspe`. This is for Freescale's and IBM e500 CPUs.

`uname -p` returns subarchitecture name, so `powerpc`, `powerpc64` or `powerpcspe`.
It would seem that the most portable approach would be to detect `power` and expose it as either `ppc32` or `ppc64` in Meson scripts. Does this seem reasonable?

Resolving patch:
diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
--- a/mesonbuild/environment.py
+++ b/mesonbuild/environment.py
@@ -211,6 +211,19 @@ def detect_cpu_family(compilers):
         return 'arm'
     if trial.startswith('ppc64'):
         return 'ppc64'
+    if trial == 'powerpc':
+        # FreeBSD calls both ppc and ppc64 "powerpc".
+        # https://github.com/mesonbuild/meson/issues/4397
+        try:
+            p, stdo, _ = Popen_safe(['uname', '-p'])
+        except (FileNotFoundError, PermissionError):
+            # Not much to go on here.
+            if sys.maxsize > 2**32:
+                return 'ppc64'
+            return 'ppc'
+        if 'powerpc64' in stdo:
+            return 'ppc64'
+        return 'ppc'
     if trial in ('amd64', 'x64'):
         trial = 'x86_64'
     if trial == 'x86_64':


Test patch:
Repository: mesonbuild/meson

Issue:
If Meson fails to find boost, it crashes with error "TypeError: get_library_dirs() takes 0 positional arguments but 1 was given"
Tested with meson 0.48.1

Full stack trace

```
Traceback (most recent call last):
  File "mesonbuild/mesonmain.py", line 364, in run
    app.generate()
  File "mesonbuild/mesonmain.py", line 136, in generate
    self._generate(env)
  File "mesonbuild/mesonmain.py", line 165, in _generate
    intr.run()
  File "mesonbuild/interpreter.py", line 3836, in run
    super().run()
  File "mesonbuild/interpreterbase.py", line 380, in run
    self.evaluate_codeblock(self.ast, start=1)
  File "mesonbuild/interpreterbase.py", line 404, in evaluate_codeblock
    raise e
  File "mesonbuild/interpreterbase.py", line 398, in evaluate_codeblock
    self.evaluate_statement(cur)
  File "mesonbuild/interpreterbase.py", line 411, in evaluate_statement
    return self.assignment(cur)
  File "mesonbuild/interpreterbase.py", line 946, in assignment
    value = self.evaluate_statement(node.value)
  File "mesonbuild/interpreterbase.py", line 409, in evaluate_statement
    return self.function_call(cur)
  File "mesonbuild/interpreterbase.py", line 705, in function_call
    return func(node, posargs, kwargs)
  File "mesonbuild/interpreterbase.py", line 273, in wrapped
    return f(*wrapped_args, **wrapped_kwargs)
  File "mesonbuild/interpreterbase.py", line 273, in wrapped
    return f(*wrapped_args, **wrapped_kwargs)
  File "mesonbuild/interpreterbase.py", line 162, in wrapped
    return f(*wrapped_args, **wrapped_kwargs)
  File "mesonbuild/interpreter.py", line 2998, in func_dependency
    dep = dependencies.find_external_dependency(name, self.environment, kwargs)
  File "mesonbuild/dependencies/base.py", line 1455, in find_external_dependency
    raise pkg_exc
  File "mesonbuild/dependencies/base.py", line 1409, in find_external_dependency
    d = c()
  File "mesonbuild/dependencies/boost.py", line 145, in __init__
    self.detect_lib_modules()
  File "mesonbuild/dependencies/boost.py", line 271, in detect_lib_modules
    self.detect_lib_modules_nix()
  File "mesonbuild/dependencies/boost.py", line 446, in detect_lib_modules_nix
    libdirs = mesonlib.get_library_dirs(self.env)
TypeError: get_library_dirs() takes 0 positional arguments but 1 was given
```



Discussion:

Resolving patch:
diff --git a/mesonbuild/dependencies/boost.py b/mesonbuild/dependencies/boost.py
--- a/mesonbuild/dependencies/boost.py
+++ b/mesonbuild/dependencies/boost.py
@@ -443,7 +443,7 @@ def detect_lib_modules_nix(self):
         if self.libdir:
             libdirs = [self.libdir]
         elif self.boost_root is None:
-            libdirs = mesonlib.get_library_dirs(self.env)
+            libdirs = mesonlib.get_library_dirs()
         else:
             libdirs = [os.path.join(self.boost_root, 'lib')]
         for libdir in libdirs:


Test patch:
Repository: mesonbuild/meson

Issue:
Gnome-initial-setup is broken
https://build.gnome.org/continuous/buildmaster/builds/2018/10/25/27/build/log-gnome-initial-setup.txt

Git bisect says the cause is this: https://github.com/mesonbuild/meson/commit/176af2c8c33


Discussion:

Resolving patch:
diff --git a/mesonbuild/modules/i18n.py b/mesonbuild/modules/i18n.py
--- a/mesonbuild/modules/i18n.py
+++ b/mesonbuild/modules/i18n.py
@@ -85,6 +85,10 @@ def merge_file(self, state, args, kwargs):
         if hasattr(inputfile, 'held_object'):
             ct = build.CustomTarget(kwargs['output'] + '_merge', state.subdir, state.subproject, kwargs)
         else:
+            if isinstance(inputfile, list):
+                # We only use this input file to create a name of the custom target.
+                # Thus we can ignore the other entries.
+                inputfile = inputfile[0]
             if isinstance(inputfile, str):
                 inputfile = mesonlib.File.from_source_file(state.environment.source_dir,
                                                            state.subdir, inputfile)


Test patch:
diff --git a/test cases/frameworks/6 gettext/data/meson.build b/test cases/frameworks/6 gettext/data/meson.build
--- a/test cases/frameworks/6 gettext/data/meson.build	
+++ b/test cases/frameworks/6 gettext/data/meson.build	
@@ -10,7 +10,7 @@ i18n.merge_file(
 
 # Use filename substitution for another file
 i18n.merge_file(
-  input: 'test2.desktop.in',
+  input: files('test2.desktop.in'),
   output: '@BASENAME@',
   type: 'desktop',
   po_dir: '../po',