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

Issue:
meson configure -Doption=unknown-value fails with a traceback
Compare:

```console
$ meson configure build -Dman=asdf
Traceback (most recent call last):
  File "/usr/bin/meson", line 37, in <module>
    sys.exit(main())
  File "/usr/bin/meson", line 34, in main
    return mesonmain.run(sys.argv[1:], launcher)
  File "/usr/lib/python3.6/site-packages/mesonbuild/mesonmain.py", line 302, in run
    return mconf.run(remaining_args)
  File "/usr/lib/python3.6/site-packages/mesonbuild/mconf.py", line 279, in run
    c.set_options(options.sets)
  File "/usr/lib/python3.6/site-packages/mesonbuild/mconf.py", line 130, in set_options
    tgt.set_value(v)
  File "/usr/lib/python3.6/site-packages/mesonbuild/coredata.py", line 131, in set_value
    raise MesonException('Value "%s" for combo option "%s" is not one of the choices. Possible choices are: %s.' % (newvalue, self.name, optionsstring))
mesonbuild.mesonlib.MesonException: Value "asdf" for combo option "man" is not one of the choices. Possible choices are: "auto", "true", "false".
$ meson build-tmp -Dman=asdf
The Meson build system
Version: 0.43.0
Source dir: /home/zbyszek/src/systemd
Build dir: /home/zbyszek/src/systemd/build-tmp
Build type: native build

Meson encountered an error in file meson_options.txt, line 96, column 0:
Value "asdf" for combo option "man" is not one of the choices. Possible choices are: "auto", "true", "false".

A full log can be found at /home/zbyszek/src/systemd/build-tmp/meson-logs/meson-log.txt
```

This is with meson-0.43.0-1.fc27.noarch.


Discussion:

Resolving patch:
diff --git a/mesonbuild/mesonmain.py b/mesonbuild/mesonmain.py
--- a/mesonbuild/mesonmain.py
+++ b/mesonbuild/mesonmain.py
@@ -300,7 +300,11 @@ def run(original_args, mainfile=None):
         elif cmd_name == 'rewrite':
             return rewriter.run(remaining_args)
         elif cmd_name == 'configure':
-            return mconf.run(remaining_args)
+            try:
+                return mconf.run(remaining_args)
+            except MesonException as e:
+                mlog.log(mlog.red('\nError configuring project:'), e)
+                sys.exit(1)
         elif cmd_name == 'wrap':
             return wraptool.run(remaining_args)
         elif cmd_name == 'runpython':


Test patch:
Repository: mesonbuild/meson

Issue:
Build error when using target.extract_all_objects() when target has header sources
An issue has been discovered while working on PR #2711:

> ninja: error: 'gio/gio-2.0@sha/meson-generated_.._gnetworking.h.o', needed by 'gio/libgio-2.0.a', missing and no known rule to make it

According to @nirbheek it is a bug in extract_all_objects():
> I've seen this bug before elsewhere. It's because when figuring out the list of sources to use in extract_all_objects(), we don't skip over headers. See the sources classification in backends/ninjabackend.py:NinjaBackend.generate_target(). Specifically, look at how we handle the contents oftarget_sources and generated_sources.
>
>This file classification needs to be factored out and probably moved to the BuildTarget object so it can also be used by extract_all_objects().


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
@@ -342,6 +342,11 @@ def object_filename_from_source(self, target, source, is_unity):
         assert isinstance(source, mesonlib.File)
         build_dir = self.environment.get_build_dir()
         rel_src = source.rel_to_builddir(self.build_to_src)
+
+        if (not self.environment.is_source(rel_src) or
+           self.environment.is_header(rel_src)) and not is_unity:
+            return None
+
         # foo.vala files compile down to foo.c and then foo.c.o, not foo.vala.o
         if rel_src.endswith(('.vala', '.gs')):
             # See description in generate_vala_compile for this logic.
@@ -389,8 +394,9 @@ def determine_ext_objs(self, target, extobj, proj_dir_to_build_root):
             return [objpath]
         for osrc in extobj.srclist:
             objname = self.object_filename_from_source(extobj.target, osrc, False)
-            objpath = os.path.join(proj_dir_to_build_root, targetdir, objname)
-            result.append(objpath)
+            if objname:
+                objpath = os.path.join(proj_dir_to_build_root, targetdir, objname)
+                result.append(objpath)
         return result
 
     def get_pch_include_args(self, compiler, target):


Test patch:
Repository: mesonbuild/meson

Issue:
boost library directory on Windows when binaries for more than one toolset version are installed 
On Windows I have installed the boost binaries for all combinations of architectures (32-bit/64-bit) and toolset versions (14.0/14.1) so in `C:\Program Files\boost\boost_1_65_1` I have four library directories:
- lib32-msvc-14.0
- lib32-msvc-14.1
- lib64-msvc-14.0
- lib64-msvc-14.1

when started in a x64 native tools command prompt for VS 2017, meson thinks it has found the Boost library directory as `C:\Program Files\boost\boost_1_65_1\lib64-msvc-14.0` whereas it should be `C:\Program Files\boost\boost_1_65_1\lib64-msvc-14.1`

The [code](https://github.com/mesonbuild/meson/blob/master/mesonbuild/dependencies/misc.py#L256) is using globbing to find the first one, there is even a **FIXME** note; would it make sense to use [`compiler.c.get_toolset_version`](https://github.com/mesonbuild/meson/blob/master/mesonbuild/compilers/c.py#L1063) for that ?




Discussion:
More bugs for you, @NickeZ :)
This is kind of a known issue.. will look into it of i have time

Resolving patch:
diff --git a/mesonbuild/dependencies/misc.py b/mesonbuild/dependencies/misc.py
--- a/mesonbuild/dependencies/misc.py
+++ b/mesonbuild/dependencies/misc.py
@@ -237,17 +237,18 @@ def detect_lib_modules(self):
 
     def detect_lib_modules_win(self):
         arch = detect_cpu_family(self.env.coredata.compilers)
-        compiler_ts = self.env.detect_cpp_compiler(self.want_cross).get_toolset_version().split('.')
+        comp_ts_version = self.env.detect_cpp_compiler(self.want_cross).get_toolset_version()
+        compiler_ts = comp_ts_version.split('.')
         compiler = 'vc{}{}'.format(compiler_ts[0], compiler_ts[1])
         if not self.libdir:
-            # The libdirs in the distributed binaries
+            # The libdirs in the distributed binaries (from sf)
             if arch == 'x86':
-                gl = 'lib32*'
+                lib_sf = 'lib32-msvc-{}'.format(comp_ts_version)
             elif arch == 'x86_64':
-                gl = 'lib64*'
+                lib_sf = 'lib64-msvc-{}'.format(comp_ts_version)
             else:
                 # Does anyone do Boost cross-compiling to other archs on Windows?
-                gl = None
+                lib_sf = None
             if self.boost_root:
                 roots = [self.boost_root]
             else:
@@ -258,11 +259,10 @@ def detect_lib_modules_win(self):
                 if os.path.isdir(libdir):
                     self.libdir = libdir
                     break
-                if gl:
-                    tmp = glob.glob(os.path.join(root, gl))
-                    if len(tmp) > 0:
-                        # FIXME: Should pick the correct version
-                        self.libdir = tmp[0]
+                if lib_sf:
+                    full_path = os.path.join(root, lib_sf)
+                    if os.path.isdir(full_path):
+                        self.libdir = full_path
                         break
 
         if not self.libdir:


Test patch:
Repository: mesonbuild/meson

Issue:
Thread dependency failure when building code mixed with Vala
Building a Vala executable, which has a transitive dependency on threads results in the following error:

```
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/mesonbuild/mesonmain.py", line 352, in run
    app.generate()
  File "/usr/lib/python3.6/site-packages/mesonbuild/mesonmain.py", line 147, in generate
    self._generate(env)
  File "/usr/lib/python3.6/site-packages/mesonbuild/mesonmain.py", line 197, in _generate
    g.generate(intr)
  File "/usr/lib/python3.6/site-packages/mesonbuild/backend/ninjabackend.py", line 210, in generate
    self.generate_target(t, outfile)
  File "/usr/lib/python3.6/site-packages/mesonbuild/backend/ninjabackend.py", line 347, in generate_target
    vala_generated_sources = self.generate_vala_compile(target, outfile)
  File "/usr/lib/python3.6/site-packages/mesonbuild/backend/ninjabackend.py", line 1146, in generate_vala_compile
    args = self.generate_basic_compiler_args(target, valac)
  File "/usr/lib/python3.6/site-packages/mesonbuild/backend/backends.py", line 510, in generate_basic_compiler_args
    commands += compiler.thread_flags()
AttributeError: 'ValaCompiler' object has no attribute 'thread_flags'
```

I encountered this while trying to port gnome-sudoku. It uses a helper library, which has some C++ code in it and needs to be linked with pthreads.


Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers/vala.py b/mesonbuild/compilers/vala.py
--- a/mesonbuild/compilers/vala.py
+++ b/mesonbuild/compilers/vala.py
@@ -94,3 +94,9 @@ def find_library(self, libname, env, extra_dirs):
                 return [vapi]
         mlog.debug('Searched {!r} and {!r} wasn\'t found'.format(extra_dirs, libname))
         return None
+
+    def thread_flags(self):
+        return []
+
+    def thread_link_flags(self):
+        return []


Test patch:
Repository: mesonbuild/meson

Issue:
Passing a dummy dependency to library() doesn't work
Trying to pass a dummy dependency to library() I saw that it is suggested in the dependency() docs that one creates a dependency with name "" and required: false.

```
project('glib', 'c', 'cpp',
  version : '2.55.0',
  meson_version : '>= 0.44.0',
)
thread_dep = dependency('', required : false)
library('glib-2.0',
        dependencies: [thread_dep])
```
but this results in the following error:

```
Meson encountered an error in file meson.build, line 6, column 0:
Argument is of an unacceptable type 'Dependency'.
Must be either an external dependency (returned by find_library() or dependency()) or an internal dependency (returned by declare_dependency()).
```

What am I doing wrong?



Discussion:
Would a simple "declare_dependency()" have the same effect? (maybe the docs should recommend that instead if that's the case)
@jon-turney I believe your patch from https://github.com/mesonbuild/meson/pull/2615 caused this regression.
ah, the object returned by declare_dependency() returns true for found(), so that's not a viable replacement.

Resolving patch:
diff --git a/mesonbuild/build.py b/mesonbuild/build.py
--- a/mesonbuild/build.py
+++ b/mesonbuild/build.py
@@ -839,7 +839,7 @@ def add_deps(self, deps):
                 self.external_deps.append(extpart)
                 # Deps of deps.
                 self.add_deps(dep.ext_deps)
-            elif isinstance(dep, dependencies.ExternalDependency):
+            elif isinstance(dep, dependencies.Dependency):
                 self.external_deps.append(dep)
                 self.process_sourcelist(dep.get_sources())
             elif isinstance(dep, BuildTarget):


Test patch:
diff --git a/test cases/common/171 not-found dependency/meson.build b/test cases/common/171 not-found dependency/meson.build
--- a/test cases/common/171 not-found dependency/meson.build	
+++ b/test cases/common/171 not-found dependency/meson.build	
@@ -1,4 +1,4 @@
-project('dep-test')
+project('dep-test', 'c')
 
 dep = dependency('', required:false)
 if dep.found()
@@ -6,3 +6,6 @@ if dep.found()
 endif
 
 assert(dep.type_name() == 'not-found', 'dependency should be of type "not-found" not ' + dep.type_name())
+
+library('testlib', 'testlib.c', dependencies: [dep])
+subdir('sub', if_found: dep)
diff --git a/test cases/common/171 not-found dependency/sub/meson.build b/test cases/common/171 not-found dependency/sub/meson.build
new file mode 100644
--- /dev/null
+++ b/test cases/common/171 not-found dependency/sub/meson.build	
@@ -0,0 +1 @@
+error('should be disabled by subdir(if_found:)')
diff --git a/test cases/common/171 not-found dependency/testlib.c b/test cases/common/171 not-found dependency/testlib.c
new file mode 100644
Repository: mesonbuild/meson

Issue:
Improve "Ninja does not support newlines in rules." diagnostic
I made some changes to the AST Korn shell Meson config scripts and was surprised to see the `Ninja does not support newlines in rules.` error. I determined after a couple of hours of debugging it was due to a script, run via `run_command()`, that output a string containing a trailing newline. I didn't figure out what the problem was until I modified the `raise MesonException()` in *ninjabackend.py* to also show me the value of the  `text` variable. Once I saw the problematic text string it was obvious what the problem was. Please consider always displaying the offending value of `text` in that error message.

P.S., Thank you for the awesome build system. Switching AST Korn shell from its legacy Nmake build system to Meson has dramatically improved the build time (at least an order of magnitude) and  has made it much easier to debug build failures -- this issue notwithstanding.


Discussion:

Resolving patch:
diff --git a/mesonbuild/backend/ninjabackend.py b/mesonbuild/backend/ninjabackend.py
--- a/mesonbuild/backend/ninjabackend.py
+++ b/mesonbuild/backend/ninjabackend.py
@@ -42,8 +42,12 @@ def ninja_quote(text):
     for char in ('$', ' ', ':'):
         text = text.replace(char, '$' + char)
     if '\n' in text:
-        raise MesonException('Ninja does not support newlines in rules. '
-                             'Please report this error with a test case to the Meson bug tracker.')
+        errmsg = '''Ninja does not support newlines in rules. The content was:
+
+%s
+
+Please report this error with a test case to the Meson bug tracker.''' % text
+        raise MesonException(errmsg)
     return text
 
 


Test patch:
Repository: mesonbuild/meson

Issue:
Strange output when find_program() fails
meson.build:
```
project('example')
foo = find_program('asd12343', required: false)
```

output:
```
$ meson build
The Meson build system
Version: 0.44.0
Source dir: /mem/test
Build dir: /mem/test/build
Build type: native build
Project name: example
Build machine cpu family: x86_64
Build machine cpu: x86_64
Program asd12343 found: NO
Program nonexistingprogram found: NO       <- bug
Build targets in project: 0
Found ninja-1.8.2 at /usr/bin/ninja
```

I've highlighted the strange line.
  


Discussion:

Resolving patch:
diff --git a/mesonbuild/dependencies/__init__.py b/mesonbuild/dependencies/__init__.py
--- a/mesonbuild/dependencies/__init__.py
+++ b/mesonbuild/dependencies/__init__.py
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 from .base import (  # noqa: F401
-    Dependency, DependencyException, DependencyMethods, ExternalProgram,
+    Dependency, DependencyException, DependencyMethods, ExternalProgram, NonExistingExternalProgram,
     ExternalDependency, ExternalLibrary, ExtraFrameworkDependency, InternalDependency,
     PkgConfigDependency, find_external_dependency, get_dep_identifier, packages, _packages_accept_language)
 from .dev import GMockDependency, GTestDependency, LLVMDependency, ValgrindDependency
diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
--- a/mesonbuild/dependencies/base.py
+++ b/mesonbuild/dependencies/base.py
@@ -754,6 +754,17 @@ def get_path(self):
     def get_name(self):
         return self.name
 
+class NonExistingExternalProgram(ExternalProgram):
+
+    def __init__(self):
+        super().__init__(name = 'nonexistingprogram', silent = True)
+
+    def __repr__(self):
+        r = '<{} {!r} -> {!r}>'
+        return r.format(self.__class__.__name__, self.name, self.command)
+
+    def found(self):
+        return False
 
 class ExternalLibrary(ExternalDependency):
     def __init__(self, name, link_args, environment, language, silent=False):
diff --git a/mesonbuild/interpreter.py b/mesonbuild/interpreter.py
--- a/mesonbuild/interpreter.py
+++ b/mesonbuild/interpreter.py
@@ -2119,7 +2119,7 @@ def func_find_program(self, node, args, kwargs):
         if required and (progobj is None or not progobj.found()):
             raise InvalidArguments('Program "%s" not found or not executable' % args[0])
         if progobj is None:
-            return ExternalProgramHolder(dependencies.ExternalProgram('nonexistingprogram'))
+            return ExternalProgramHolder(dependencies.NonExistingExternalProgram())
         return progobj
 
     def func_find_library(self, node, args, kwargs):


Test patch:
Repository: mesonbuild/meson

Issue:
Request to add project_license() method to the meson object
Hi,

In the `meson` builtin object, we have `project_version()` but not `project_license()`, which would be handy for, say, auto-generation of manifest files or similar. It would be useful to add this.

if I get some time, I'll add this myself, but I thought I'd mention it in any case.


Discussion:

Resolving patch:
diff --git a/mesonbuild/interpreter.py b/mesonbuild/interpreter.py
--- a/mesonbuild/interpreter.py
+++ b/mesonbuild/interpreter.py
@@ -1168,6 +1168,7 @@ def __init__(self, build, interpreter):
                              'add_postconf_script': self.add_postconf_script_method,
                              'install_dependency_manifest': self.install_dependency_manifest_method,
                              'project_version': self.project_version_method,
+                             'project_license': self.project_license_method,
                              'version': self.version_method,
                              'project_name': self.project_name_method,
                              'get_cross_property': self.get_cross_property_method,
@@ -1281,6 +1282,9 @@ def install_dependency_manifest_method(self, args, kwargs):
     def project_version_method(self, args, kwargs):
         return self.build.dep_manifest[self.interpreter.active_projectname]['version']
 
+    def project_license_method(self, args, kwargs):
+        return self.build.dep_manifest[self.interpreter.active_projectname]['license']
+
     def version_method(self, args, kwargs):
         return coredata.version
 


Test patch:
diff --git a/test cases/common/175 get project license/bar.c b/test cases/common/175 get project license/bar.c
new file mode 100644
--- /dev/null
+++ b/test cases/common/175 get project license/bar.c	
@@ -0,0 +1,6 @@
+#include<stdio.h>
+
+int main(int argc, char **argv) {
+    printf("I'm a main project bar.\n");
+    return 0;
+}
diff --git a/test cases/common/175 get project license/meson.build b/test cases/common/175 get project license/meson.build
new file mode 100644
--- /dev/null
+++ b/test cases/common/175 get project license/meson.build	
@@ -0,0 +1,8 @@
+project('bar', 'c', license: 'Apache')
+
+executable('bar', 'bar.c')
+
+license = meson.project_license()[0]
+if license != 'Apache'
+    error('The license should be Apache, but it is: ' + license)
+endif
Repository: mesonbuild/meson

Issue:
Meson rebuilds everything on meson.build file change
Hi,
Meson seems to rebuild every obj file on any meson.build change (even touch).
That's not a Ninja issue as CMake+Ninja does not have this behaviour. Does Meson internally store build informations, to know which targets need rebuild ?


Discussion:
No. This might be caused by timestamps getting out of whack (though it is very rare). If this keeps happening, post specific details of your setup.
That's strange. I've been using Meson on windows, multiple linux distros, multiple PCs, and ever had that behaviour. 

EDIT : That's related to a `configure_file`'d `config.h` : 

    ninja explain: output libs/rgbe/rgbe@sta/rgbe.c.o older than most recent input config.h (1516357787 vs 1516357810)
    ninja explain: libs/rgbe/rgbe@sta/rgbe.c.o is dirty

That means the configuration used for the configure_file is not detected as "unchanged" even if it didn't change… And that this configure_file is used as input for *every* target (well, why not).

Meson should re-write the configure_file only if its content changed (the easiest way would be to write a temp file, compare both files, and replace if needed).

Resolving patch:
diff --git a/mesonbuild/mesonlib.py b/mesonbuild/mesonlib.py
--- a/mesonbuild/mesonlib.py
+++ b/mesonbuild/mesonlib.py
@@ -576,7 +576,8 @@ def do_conf_file(src, dst, confdata):
     return missing_variables
 
 def dump_conf_header(ofilename, cdata):
-    with open(ofilename, 'w', encoding='utf-8') as ofile:
+    ofilename_tmp = ofilename + '~'
+    with open(ofilename_tmp, 'w', encoding='utf-8') as ofile:
         ofile.write('''/*
  * Autogenerated by the Meson build system.
  * Do not edit, your changes will be lost.
@@ -598,6 +599,7 @@ def dump_conf_header(ofilename, cdata):
                 ofile.write('#define %s %s\n\n' % (k, v))
             else:
                 raise MesonException('Unknown data type in configuration file entry: ' + k)
+    replace_if_different(ofilename, ofilename_tmp)
 
 def replace_if_different(dst, dst_tmp):
     # If contents are identical, don't touch the file to prevent


Test patch:
Repository: mesonbuild/meson

Issue:
Print URI to HTML coverage report from coverage-html target
Once the `coverage-html` target has finished running successfully, it would be useful if it printed a `file:///` URI pointing to the index of the generated coverage report, so that it’s easy to open the report from a terminal window in a browser.


Discussion:

Resolving patch:
diff --git a/mesonbuild/scripts/coverage.py b/mesonbuild/scripts/coverage.py
--- a/mesonbuild/scripts/coverage.py
+++ b/mesonbuild/scripts/coverage.py
@@ -14,7 +14,7 @@
 
 from mesonbuild import environment
 
-import sys, os, subprocess
+import sys, os, subprocess, pathlib
 
 def remove_dir_from_trace(lcov_command, covfile, dirname):
     tmpfile = covfile + '.tmp'
@@ -68,6 +68,15 @@ def coverage(source_root, build_root, log_dir):
                                '--show-details',
                                '--branch-coverage',
                                covinfo])
+    if gcovr_exe:
+        print('')
+        print('XML coverage report can be found at',
+              pathlib.Path(log_dir, 'coverage.xml').as_uri())
+        print('Text coverage report can be found at',
+              pathlib.Path(log_dir, 'coverage.txt').as_uri())
+    if lcov_exe and genhtml_exe:
+        print('Html coverage report can be found at',
+              pathlib.Path(htmloutdir, 'index.html').as_uri())
     return 0
 
 def run(args):


Test patch: