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

Issue:
header-only boost dependencies conflict with static boost dependencies
**Describe the bug**
Starting with v 0.54.0:
Using a header-only boost dependency in combination with a static boost dependency results in
 conflicting BOOST_XXX_DYN_LINK and BOOST_XXX_STATIC_LINK preprocessor defines.

For example:
`error: #error Must not define both BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK 
`
The boost dependencies might come from different, unrelated subprojects.
The header-only dependency introduces the *DYN_LINK, despite (I'm assuming here)
that header-only dependencies should be dynamic or static neutral.


**To Reproduce**

Introduce a header-only boost dependency and a static boost dependency in the same project,
possibly, but not necessarily, coming from different subprojects.

`$ cat meson.build
project('static_headonly', 'cpp',
  default_options : ['warning_level=3',
                     'cpp_std=c++11'])

boost_headers_dep = dependency('boost')

boost_fs_dep = dependency('boost', modules: ['filesystem', 'system'], static: true)

exe = executable(
  'static_headonly', 'static_headonly.cpp',
  dependencies: [boost_headers_dep, boost_fs_dep],
  install : true)

$ cat static_headonly.cpp
#include <iostream>
#include <iterator>

#include "boost/filesystem.hpp"

int main() {

    std::cout << "directory entries: "
        << std::distance(boost::filesystem::directory_iterator("."),
                boost::filesystem::directory_iterator())
        << "\n";
}
`

`error: #error Must not define both BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK 
`

**Expected behavior**

The build should succeed.

I would expect a header-only dependency to not define a
*DYN_LINK preprocessor name. 

**system parameters**

$ g++ --version
g++ (Debian 4.7.2-5) 4.7.2
$ python --version
Python 2.7.17 :: Anaconda, Inc.
$ uname -a
Linux osslab01 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux
$ ninja --version
1.8.2
$ meson --version
0.54.1


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
@@ -637,11 +637,8 @@ def _include_dir_from_version_header(self, hfile: Path) -> BoostIncludeDir:
         return BoostIncludeDir(hfile.parents[1], int(m.group(1)))
 
     def _extra_compile_args(self) -> T.List[str]:
-        args = []  # type: T.List[str]
-        args += ['-DBOOST_ALL_NO_LIB']  # Disable automatic linking
-        if not self.static:
-            args += ['-DBOOST_ALL_DYN_LINK']
-        return args
+        # BOOST_ALL_DYN_LINK should not be required with the known defines below
+        return ['-DBOOST_ALL_NO_LIB']  # Disable automatic linking
 
 
 # See https://www.boost.org/doc/libs/1_72_0/more/getting_started/unix-variants.html#library-naming


Test patch:
Repository: mesonbuild/meson

Issue:
boost dependency static libs require static: true (instead of missing) even when dynamic libs are absent
**Describe the bug**
I have a Boost instance that contains only static libraries.
Until v 0.54.0, the boost dependency would find them without requiring me to specify `static: true`.

**To Reproduce**

Call a boost dependency for a module against a Boost installation without dynamic libraries.
Don't use the `static` keyword.

The dependency will fail to locate the static library.


**Expected behavior**
As long as I don't specify a static keyword, the boost dependency should first search for dynamic 
libraries, and then search for static libraries. If I don't care whether I match static or dynamic,
I should be able to pick up static libraries if dynamic libs don't exist.

If this expected behavior is wrong, then update the dependency documentation to describe the default behavior and rationale for when a dependency static keyword is missing.

**system parameters**
v 0.54.0, 0.54.1

Thanks!


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
@@ -344,6 +344,7 @@ def __init__(self, environment: Environment, kwargs):
         self.multithreading = kwargs.get('threading', 'multi') == 'multi'
 
         self.boost_root = None
+        self.explicit_static = 'static' in kwargs
 
         # Extract and validate modules
         self.modules = mesonlib.extract_as_list(kwargs, 'modules')  # type: T.List[str]
@@ -522,7 +523,7 @@ def filter_libraries(self, libs: T.List[BoostLibraryFile], lib_vers: str) -> T.L
         except (KeyError, IndexError, AttributeError):
             pass
 
-        libs = [x for x in libs if x.static == self.static]
+        libs = [x for x in libs if x.static == self.static or not self.explicit_static]
         libs = [x for x in libs if x.mt == self.multithreading]
         libs = [x for x in libs if x.version_matches(lib_vers)]
         libs = [x for x in libs if x.arch_matches(self.arch)]


Test patch:
Repository: mesonbuild/meson

Issue:
meson_options.txt don't allow splitting long strings nicely
Currently `meson_options.txt` don't provide a way to split long strings in multiple lines. If I try to use the `+` operator, the syntax is rejected. My use case is the `description` value. Descriptions can be long to be useful, but I don't like writing anything beyond the 80-column barrier and would rather break this long line.


Discussion:

Resolving patch:
diff --git a/mesonbuild/optinterpreter.py b/mesonbuild/optinterpreter.py
--- a/mesonbuild/optinterpreter.py
+++ b/mesonbuild/optinterpreter.py
@@ -171,12 +171,21 @@ def reduce_single(self, arg):
             res = self.reduce_single(arg.value)
             if not isinstance(res, (int, float)):
                 raise OptionException('Token after "-" is not a number')
+            FeatureNew.single_use('negative numbers in meson_options.txt', '0.54.1', self.subproject)
             return -res
         elif isinstance(arg, mparser.NotNode):
             res = self.reduce_single(arg.value)
             if not isinstance(res, bool):
                 raise OptionException('Token after "not" is not a a boolean')
+            FeatureNew.single_use('negation ("not") in meson_options.txt', '0.54.1', self.subproject)
             return not res
+        elif isinstance(arg, mparser.ArithmeticNode):
+            l = self.reduce_single(arg.left)
+            r = self.reduce_single(arg.right)
+            if not (arg.operation == 'add' and isinstance(l, str) and isinstance(r, str)):
+                raise OptionException('Only string concatenation with the "+" operator is allowed')
+            FeatureNew.single_use('string concatenation in meson_options.txt', '0.55.0', self.subproject)
+            return l + r
         else:
             raise OptionException('Arguments may only be string, int, bool, or array of those.')
 


Test patch:
diff --git a/test cases/common/43 options/meson_options.txt b/test cases/common/43 options/meson_options.txt
--- a/test cases/common/43 options/meson_options.txt	
+++ b/test cases/common/43 options/meson_options.txt	
@@ -1,7 +1,7 @@
-option('testoption', type : 'string', value : 'optval', description : 'An option to do something')
+option('testoption', type : 'string', value : 'optval', description : 'An option ' + 'to do something')
 option('other_one', type : 'boolean', value : not (not (not (not false))))
-option('combo_opt', type : 'combo', choices : ['one', 'two', 'combo'], value : 'combo')
+option('combo_opt', type : 'co' + 'mbo', choices : ['one', 'two', 'combo'], value : 'combo')
 option('array_opt', type : 'array', choices : ['one', 'two', 'three'], value : ['one', 'two'])
 option('free_array_opt', type : 'array')
 option('integer_opt', type : 'integer', min : 0, max : -(-5), value : 3)
-option('neg_int_opt', type : 'integer', min : -5, max : 5, value : -3)
+option('neg' + '_' + 'int' + '_' + 'opt', type : 'integer', min : -5, max : 5, value : -3)
Repository: mesonbuild/meson

Issue:
Report which command line variable has wrong value
Sometimes projects change the type of a meson option, for example from boolean to feature.
Meson then gives an error like this:
```
meson.build:1:0: ERROR: Value "false" for combo option is not one of the choices. Possible choices are: "enabled", "disabled", "auto".
```
Which means I have to spend some time figuring out which option changed.
Would it be possible to mention which option has a wrong value? For example by changing the first sentence of the error to: _Value "false" for combo option **some_option** is not one of the choices._ 


Discussion:

Resolving patch:
diff --git a/mesonbuild/coredata.py b/mesonbuild/coredata.py
--- a/mesonbuild/coredata.py
+++ b/mesonbuild/coredata.py
@@ -161,7 +161,9 @@ def __init__(self, description, choices: T.List[str], value, yielding=None):
     def validate_value(self, value):
         if value not in self.choices:
             optionsstring = ', '.join(['"%s"' % (item,) for item in self.choices])
-            raise MesonException('Value "%s" for combo option is not one of the choices. Possible choices are: %s.' % (value, optionsstring))
+            raise MesonException('Value "{}" for combo option "{}" is not one of the choices.'
+                                 ' Possible choices are: {}.'.format(
+                                     value, self.description, optionsstring))
         return value
 
 class UserArrayOption(UserOption[T.List[str]]):


Test patch:
Repository: mesonbuild/meson

Issue:
The b_ndebug option doesn't define NDEBUG with MSVC
When setting the option `b_ndebug` to `if-release` or `true`, the `NDEBUG` macro is not correctly defined for the msvc compiler.

**To Reproduce**

*meson.build*
```
project('myProject', 'cpp',
  version : '0.1',
  default_options : ['b_ndebug=true'])

exe = executable('exe', 'main.cpp')
```

*main.cpp*
```
#ifdef NDEBUG
#pragma message("NDEBUG is defined")
#else
#pragma message("NDEBUG is not defined")
#endif

int main() { return 0; }
```

In a VS BuildTools prompt:
```
meson build
ninja -C build
```
ninja output:
```
ninja: Entering directory `build'
[1/2] Compiling C++ object exe@exe/main.cpp.obj.
NDEBUG is not defined
[2/2] Linking target exe.exe.
```

**Expected behavior**
Compilation should output  `NDEBUG is defined`.

**System parameters**
* It's a plain native build
* OS: Windows 10
* Python version: 2.7.17 (I know python < 3 is deprecated but I don't think it's a matter here)
* Meson version: 0.53.1
* Ninja version: 1.9.0



Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers/cpp.py b/mesonbuild/compilers/cpp.py
--- a/mesonbuild/compilers/cpp.py
+++ b/mesonbuild/compilers/cpp.py
@@ -577,7 +577,7 @@ def __init__(self, exelist, version, for_machine: MachineChoice,
                  is_cross: bool, info: 'MachineInfo', exe_wrap, target, **kwargs):
         CPPCompiler.__init__(self, exelist, version, for_machine, is_cross, info, exe_wrap, **kwargs)
         MSVCCompiler.__init__(self, target)
-        self.base_options = ['b_pch', 'b_vscrt'] # FIXME add lto, pgo and the like
+        self.base_options = ['b_pch', 'b_vscrt', 'b_ndebug'] # FIXME add lto, pgo and the like
         self.id = 'msvc'
 
     def get_options(self):


Test patch:
diff --git a/test cases/windows/17 msvc ndebug/main.cpp b/test cases/windows/17 msvc ndebug/main.cpp
new file mode 100644
--- /dev/null
+++ b/test cases/windows/17 msvc ndebug/main.cpp	
@@ -0,0 +1,9 @@
+int main() {
+#ifdef NDEBUG
+    // NDEBUG is defined
+    return 0;
+#else
+    // NDEBUG is not defined
+    return 1;
+#endif
+}
\ No newline at end of file
diff --git a/test cases/windows/17 msvc ndebug/meson.build b/test cases/windows/17 msvc ndebug/meson.build
new file mode 100644
--- /dev/null
+++ b/test cases/windows/17 msvc ndebug/meson.build	
@@ -0,0 +1,7 @@
+project('msvc_ndebug', 'cpp',
+    default_options : [ 'b_ndebug=true' ]
+)
+
+exe = executable('exe', 'main.cpp')
+
+test('ndebug', exe)
Repository: mesonbuild/meson

Issue:
disabler() objects convert arrays into non-arrays
When an array is used to contain a bunch of built objects, e.g. executable()s , if any of those objects becomes a disabler() object, the array stops being an array, and syntactic breakage occurs.

For example:
```python
project('list-of-disablers', 'c',
        version : '2.35-rc2',
        license : 'GPLv2+')
exes = []

exes += executable(
  'foo',
  'foo.c')

exes += executable(
  'foo2',
  'foo.c',
  dependencies : disabler())

exes += executable(       #here
  'foo3',
  'foo.c')
```
This fails with:
```
../meson.build:16:0: ERROR: The += operator currently only works with arrays, dicts, strings or ints 
```
because fails because `exes` is suddenly not an array any more, but a disabler() object. This is just not terribly useful. Instead of changing the types, disabled object need to keep their type, but just get disabled.

meson-0.54.0-1.fc32.noarch


Discussion:
Ooof, that's bad. We really should still get a list of objects, which include a `disabler()` at that point.

Resolving patch:
diff --git a/mesonbuild/interpreterbase.py b/mesonbuild/interpreterbase.py
--- a/mesonbuild/interpreterbase.py
+++ b/mesonbuild/interpreterbase.py
@@ -810,9 +810,7 @@ def evaluate_plusassign(self, node: mparser.PlusAssignmentNode) -> None:
         assert(isinstance(node, mparser.PlusAssignmentNode))
         varname = node.var_name
         addition = self.evaluate_statement(node.value)
-        if is_disabler(addition):
-            self.set_variable(varname, addition)
-            return
+
         # Remember that all variables are immutable. We must always create a
         # full new variable and then assign it.
         old_variable = self.get_variable(varname)
@@ -836,7 +834,7 @@ def evaluate_plusassign(self, node: mparser.PlusAssignmentNode) -> None:
             new_value = {**old_variable, **addition}
         # Add other data types here.
         else:
-            raise InvalidArguments('The += operator currently only works with arrays, dicts, strings or ints ')
+            raise InvalidArguments('The += operator currently only works with arrays, dicts, strings or ints')
         self.set_variable(varname, new_value)
 
     def evaluate_indexing(self, node: mparser.IndexNode) -> TYPE_var:


Test patch:
diff --git a/test cases/common/235 disabler array addition/meson.build b/test cases/common/235 disabler array addition/meson.build
new file mode 100644
--- /dev/null
+++ b/test cases/common/235 disabler array addition/meson.build	
@@ -0,0 +1,9 @@
+project('disabler_inside_array', 'c')
+
+exes = []
+
+exes += library('a', 'test.c')
+
+exes += library('b', 'test.c', dependencies : disabler())
+
+exes += library('c', 'test.c')
diff --git a/test cases/common/235 disabler array addition/test.c b/test cases/common/235 disabler array addition/test.c
new file mode 100644
--- /dev/null
+++ b/test cases/common/235 disabler array addition/test.c	
@@ -0,0 +1 @@
+int stub(void) { return 0; }
Repository: mesonbuild/meson

Issue:
Support c_std=c11 for newer MSVC 2019
Although I haven't found any mention of this in the [16.7 release notes](https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#16.7.0) `/std:c11` (and only `c11`) is supported for this version, this enables C11 _Generic support which has been a [preview feature](https://developercommunity.visualstudio.com/comments/1039772/view.html) for a while.


Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers/c.py b/mesonbuild/compilers/c.py
--- a/mesonbuild/compilers/c.py
+++ b/mesonbuild/compilers/c.py
@@ -353,6 +353,26 @@ def __init__(self, exelist, version, for_machine: MachineChoice,
                            info, exe_wrap, **kwargs)
         MSVCCompiler.__init__(self, target)
 
+    def get_options(self):
+        opts = super().get_options()
+        c_stds = ['none', 'c89', 'c99', 'c11']
+        opts.update({
+            'std': coredata.UserComboOption(
+                'C language standard to use',
+                c_stds,
+                'none',
+            ),
+        })
+        return opts
+
+    def get_option_compile_args(self, options):
+        args = []
+        std = options['std']
+        # As of MVSC 16.7, /std:c11 is the only valid C standard option.
+        if std.value in {'c11'}:
+            args.append('/std:' + std.value)
+        return args
+
 
 class ClangClCCompiler(ClangClCompiler, VisualStudioLikeCCompilerMixin, CCompiler):
     def __init__(self, exelist, version, for_machine: MachineChoice,


Test patch:
Repository: mesonbuild/meson

Issue:
Qt5 modules should not always require uic
Qt5 can be built without `uic` (if widgets are disable). This is quite common for embedded use-cases with QtQuick only applications.

Currently meson fails because it always requires `uic`. I'm not sure what the correct fix is.
Maybe handle this like `lrelease`?


Discussion:
It should probably only try to look up uic once the build definition contains an ui build rule.
Is there a workaround for this?
This could be a nice little contribution, lrelease is already optional. See https://github.com/mesonbuild/meson/blob/master/mesonbuild/modules/qt.py#L40 and https://github.com/mesonbuild/meson/blob/master/mesonbuild/dependencies/ui.py#L225

Resolving patch:
diff --git a/mesonbuild/dependencies/ui.py b/mesonbuild/dependencies/ui.py
--- a/mesonbuild/dependencies/ui.py
+++ b/mesonbuild/dependencies/ui.py
@@ -234,13 +234,13 @@ def compilers_detect(self, interp_obj):
         def gen_bins():
             for b in bins:
                 if self.bindir:
-                    yield os.path.join(self.bindir, b), b, False
+                    yield os.path.join(self.bindir, b), b
                 # prefer the <tool>-qt<version> of the tool to the plain one, as we
                 # don't know what the unsuffixed one points to without calling it.
-                yield '{}-{}'.format(b, self.name), b, False
-                yield b, b, self.required if b != 'lrelease' else False
+                yield '{}-{}'.format(b, self.name), b
+                yield b, b
 
-        for b, name, required in gen_bins():
+        for b, name in gen_bins():
             if found[name].found():
                 continue
 
@@ -260,7 +260,7 @@ def get_version(p):
                     care = err
                 return care.split(' ')[-1].replace(')', '')
 
-            p = interp_obj.find_program_impl([b], required=required,
+            p = interp_obj.find_program_impl([b], required=False,
                                              version_func=get_version,
                                              wanted=wanted).held_object
             if p.found():


Test patch:
Repository: mesonbuild/meson

Issue:
gnome compile_resources doesn't work in C++ projects
**Describe the bug**
`gnome.compile_resources` form the GNOME module always generates C source files. Those files can't be added to C++ executables.

**To Reproduce**
```
project('example', 'cpp')

gnome = import('gnome')

gtkmm = dependency('gtkmm-3.0')

gresources = gnome.compile_resources('gresources', 'main.gresource.xml')

executable(meson.project_name(), gresources, 'main.cpp', dependencies: gtkmm)
```
Gives the following error:
```
$ meson _build
The Meson build system
Version: 0.55.3
Source dir: example
Build dir: example/_build
Build type: native build
Project name: example
Project version: undefined
C++ compiler for the host machine: ccache c++ (gcc 10.2.0 "c++ (Debian 10.2.0-13) 10.2.0")
C++ linker for the host machine: c++ ld.bfd 2.35.1
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Run-time dependency gtkmm-3.0 found: YES 3.24.2
Found pkg-config: /usr/bin/pkg-config (0.29.2)

meson.build:9:0: ERROR: No host machine compiler for "gresources.c"
```

**Expected behavior**
A C++ source file should be generated named `gresources.cpp` instead of the C source file. It's possible to do that with `run_command('glib-compile-resources', '--target=gresources.cpp', '--generate-source', 'main.gresource.xml')`.

**system parameters**
* Is this a cross build: No
* what operating system: `Debian GNU/Linux bullseye/sid`
* what Python version are you using: `Python 3.8.6`
* what `meson --version`: `0.55.3`
* what `ninja --version` if it's a Ninja build: `1.10.1`



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
@@ -157,8 +157,14 @@ def compile_resources(self, state, args, kwargs):
             output = args[0] + '.gresource'
             name = args[0] + '_gresource'
         else:
-            output = args[0] + '.c'
-            name = args[0] + '_c'
+            if 'c' in state.environment.coredata.compilers.host.keys():
+                output = args[0] + '.c'
+                name = args[0] + '_c'
+            elif 'cpp' in state.environment.coredata.compilers.host.keys():
+                output = args[0] + '.cpp'
+                name = args[0] + '_cpp'
+            else:
+                raise MesonException('Compiling GResources into code is only supported in C and C++ projects')
 
         if kwargs.get('install', False) and not gresource:
             raise MesonException('The install kwarg only applies to gresource bundles, see install_header')


Test patch:
Repository: mesonbuild/meson

Issue:
meson 0.56.0 feature qt5.compile_translations(qt5.compile_translations:...) does not work
according to the changelog https://github.com/mesonbuild/meson/blob/master/docs/markdown/Release-notes-for-0.56.0.md#qt5-compile_translations-now-supports-qresource-preprocessing for 0.56.0 there should be the ability to write
```cpp
qt5.compile_translations(qresource: 'i18n.qrc')
```

the `i18n.qrc` looks like:
```
<RCC>
    <qresource>
        <file>de.ts</file>
    </qresource>
</RCC>
```

however, when running meson it results in the following error:
```
ERROR: qt.compile_translations: qresource can only contain ts files, found de.ts
```
whiiiich is a contradiction.

In my opinion there is a bug along these lines. meson should compile from `ts` to `qm` and not vice-versa.
https://github.com/mesonbuild/meson/blob/d4eec9664bb96a093b92c3e1f565806686ea0ccb/mesonbuild/modules/qt.py#L236

There seem to be no tests about this.

Am I getting something wrong? Thx for your time!

By the way, thx for this great tool! :laughing: 


Discussion:
Right, the error message is misleading and should say "can only contain qm files". Sorry for that...

Resolving patch:
diff --git a/mesonbuild/modules/qt.py b/mesonbuild/modules/qt.py
--- a/mesonbuild/modules/qt.py
+++ b/mesonbuild/modules/qt.py
@@ -236,7 +236,7 @@ def compile_translations(self, state, args, kwargs):
                 if c.endswith('.qm'):
                     ts_files.append(c.rstrip('.qm')+'.ts')
                 else:
-                    raise MesonException('qt.compile_translations: qresource can only contain ts files, found {}'.format(c))
+                    raise MesonException('qt.compile_translations: qresource can only contain qm files, found {}'.format(c))
             results = self.preprocess(state, [], {'qresources': qresource, 'rcc_extra_arguments': kwargs.get('rcc_extra_arguments', [])})
         self._detect_tools(state.environment, kwargs.get('method', 'auto'))
         translations = []


Test patch: