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

Issue:
Require parallel tools when depending on HDF5
I have an application that specifically requires the availability of `h5pcc` instead of `h5cc`: https://github.com/mesonbuild/meson/blob/39ceb677744e1f959a0db6406d51a26d78f0ab68/mesonbuild/dependencies/hdf5.py#L97-L99

In my case HDF5 is only build with parallel compatibility and therefore `h5cc` is not available. 
My current workaround is to simple edit this line and specify the other tool directly. 

It there a more appropriate workaround for this issue?
Alternatively: Is it possible to add an optional parameter to `hdf5_dep = dependency('hdf5')` e.g. `dependency('hdf5', parallel: true)`


Discussion:
According to the hdf5 build system, only `h5cc` exists, and it will be installed as `h5pcc` iff "hdf5 is being built in parallel mode".

A pointless rename which, as with many parts of the hdf5 build system and install layout, is quite pointless and just causes trouble... but as they have decreed... since they can never exist at the same time (you either build --enable-parallel or not) it seems like it would make sense to just search for both of them and treat them both as h5cc.

I don't think adding a `parallel: true` kwarg makes much sense, since e.g. the pkg-config lookup method doesn't actually care, and as a matter of fact h5pcc will return the same compiler flags too.

Resolving patch:
diff --git a/mesonbuild/dependencies/hdf5.py b/mesonbuild/dependencies/hdf5.py
--- a/mesonbuild/dependencies/hdf5.py
+++ b/mesonbuild/dependencies/hdf5.py
@@ -96,13 +96,13 @@ def __init__(self, name: str, environment: 'Environment', kwargs: T.Dict[str, T.
 
         if language == 'c':
             cenv = 'CC'
-            tools = ['h5cc']
+            tools = ['h5cc', 'h5pcc']
         elif language == 'cpp':
             cenv = 'CXX'
-            tools = ['h5c++']
+            tools = ['h5c++', 'h5pc++']
         elif language == 'fortran':
             cenv = 'FC'
-            tools = ['h5fc']
+            tools = ['h5fc', 'h5pfc']
         else:
             raise DependencyException('How did you get here?')
 


Test patch:
Repository: mesonbuild/meson

Issue:
compiler object compiles() does not track changes to the files being compiled
The compiler object compiles() method does not take into account changes to the file object being compiled. For example,

```
project('foo', 'c')
cc = meson.get_compiler('c')
test = cc.compiles(files('foo.c'))
```

won't get re-evaluated if `foo.c` changes.

I presume the same applies to link() too, but did not try.



Discussion:
The same also happens for `configure_file()` when the `input:` kwarg is used. We should probably check all API for this problem.

Resolving patch:
diff --git a/mesonbuild/interpreter/compiler.py b/mesonbuild/interpreter/compiler.py
--- a/mesonbuild/interpreter/compiler.py
+++ b/mesonbuild/interpreter/compiler.py
@@ -275,6 +275,7 @@ def alignment_method(self, args: T.Tuple[str], kwargs: 'AlignmentKw') -> int:
     def run_method(self, args: T.Tuple['mesonlib.FileOrString'], kwargs: 'CompileKW') -> 'RunResult':
         code = args[0]
         if isinstance(code, mesonlib.File):
+            self.interpreter.add_build_def_file(code)
             code = mesonlib.File.from_absolute_file(
                 code.rel_to_builddir(self.environment.source_dir))
         testname = kwargs['name']
@@ -434,6 +435,7 @@ def get_define_method(self, args: T.Tuple[str], kwargs: 'CommonKW') -> str:
     def compiles_method(self, args: T.Tuple['mesonlib.FileOrString'], kwargs: 'CompileKW') -> bool:
         code = args[0]
         if isinstance(code, mesonlib.File):
+            self.interpreter.add_build_def_file(code)
             code = mesonlib.File.from_absolute_file(
                 code.rel_to_builddir(self.environment.source_dir))
         testname = kwargs['name']
@@ -457,6 +459,7 @@ def links_method(self, args: T.Tuple['mesonlib.FileOrString'], kwargs: 'CompileK
         code = args[0]
         compiler = None
         if isinstance(code, mesonlib.File):
+            self.interpreter.add_build_def_file(code)
             code = mesonlib.File.from_absolute_file(
                 code.rel_to_builddir(self.environment.source_dir))
             suffix = code.suffix
diff --git a/unittests/allplatformstests.py b/unittests/allplatformstests.py
--- a/unittests/allplatformstests.py
+++ b/unittests/allplatformstests.py
@@ -1965,6 +1965,13 @@ def test_mixed_language_linker_check(self):
         # cxx.links with C source
         self.assertEqual(cmds[3][0], cc)
         self.assertEqual(cmds[4][0], cxx)
+        if self.backend is Backend.ninja:
+            # updating the file to check causes a reconfigure
+            #
+            # only the ninja backend is competent enough to detect reconfigured
+            # no-op builds without build targets
+            self.utime(os.path.join(testdir, 'test.c'))
+            self.assertReconfiguredBuildIsNoop()
 
     def test_ndebug_if_release_disabled(self):
         testdir = os.path.join(self.unit_test_dir, '28 ndebug if-release')


Test patch:
Repository: mesonbuild/meson

Issue:
Dlang: -Dbuildtype=minsize invokes -Os instead of -Oz for LDC
`-Dbuildtype=minsize` invokes `-Os` instead of `--Oz` for LDC

As result compiler produces binaries about 10% larger.

**system parameters**
* Is this a [cross build](https://mesonbuild.com/Cross-compilation.html) or just a plain native build (for the same computer)?
Cross build
* what `meson --version`
Current ~master



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
@@ -64,7 +64,7 @@
                          '1': ['-O1'],
                          '2': ['-O2'],
                          '3': ['-O3'],
-                         's': ['-Os'],
+                         's': ['-Oz'],
                          }  # type: T.Dict[str, T.List[str]]
 
 dmd_optimization_args = {'0': [],


Test patch:
Repository: mesonbuild/meson

Issue:
Generation of build files takes very long time 
**Describe the bug**
The generation of build files in our project takes 2 minutes in meson 0.60.2 compared to 3 seconds in meson 0.60.1. Using git bisect, the the performance regression was introduced in commit 73bac14c8fe7279037433b15b6c15bc93e9156a1.

**To Reproduce**
Cannot include any meson.build files since it is proprietary project. However, by debugging the involved meson code in the Backend class, the following characteristics was found:
* Number of calls to Backend.determine_rpath_dirs with a build.BuildTarget: 206
* Number of calls to Backend.rpaths_for_bundled_shared_libraries with a build.BuildTarget: 2434034

**Expected behavior**
The time to generate build files takes about the same as in meson 0.60.1.

**system parameters**
* Is this a [cross build](https://mesonbuild.com/Cross-compilation.html) or just a plain native build (for the same computer)? Native build
* what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.): Arch Linux (updated 2021-12-02)
* what Python version are you using e.g. 3.8.0: Python 3.9.9
* what `meson --version`: Meson 0.60.2
* what `ninja --version` if it's a Ninja build; Ninja 1.10.2



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
@@ -748,7 +748,8 @@ def get_external_rpath_dirs(self, target: build.BuildTarget) -> T.Set[str]:
                         raise MesonException(f'Invalid arg for --just-symbols, {dir} is a directory.')
         return dirs
 
-    def rpaths_for_bundled_shared_libraries(self, target: build.BuildTarget, exclude_system: bool = True) -> T.List[str]:
+    @lru_cache(maxsize=None)
+    def rpaths_for_bundled_shared_libraries(self, target: build.BuildTarget, exclude_system: bool = True) -> 'ImmutableListProtocol[str]':
         paths: T.List[str] = []
         for dep in target.external_deps:
             if not isinstance(dep, (dependencies.ExternalLibrary, dependencies.PkgConfigDependency)):


Test patch:
Repository: mesonbuild/meson

Issue:
Unknown CPU family ft32
I'm currently compiling a project for an embedded device usint a bridgetek FT902 (FT32 architecture in GCC), as I expected this is not a supported target on meson, I'm not sure what this target variable implies, but compiling with the unsupported
```
cpu_family = 'ft32'
cpu = 'ft900'
```
doesnt seem to produce any issues for me.

If there is something I can do about this let me know I'm open to contribute.


Discussion:
https://github.com/mesonbuild/meson/blob/bea735dd76db32f6ea34ab66fee496d4be2f7eb1/mesonbuild/environment.py#L297-L362

I assume you got the message from the end of that function.

If you'd like to submit a PR adding the new information then that would be great. ;)

Resolving patch:
diff --git a/mesonbuild/envconfig.py b/mesonbuild/envconfig.py
--- a/mesonbuild/envconfig.py
+++ b/mesonbuild/envconfig.py
@@ -45,6 +45,7 @@
     'csky',
     'dspic',
     'e2k',
+    'ft32',
     'ia64',
     'loongarch64',
     'm68k',


Test patch:
Repository: mesonbuild/meson

Issue:
Missing backward compat warning when passing declare_dependency() to compiler
Hi,

Starting in 0.57 one can pass declare_dependency() to compiler.has_function() etc:
```
[](https://mesonbuild.com/Release-notes-for-0-57-0.html#passing-internal-dependencies-to-the-compiler-object)Passing internal dependencies to the compiler object

Methods on the compiler object (such as compiles, links, has_header) can be passed dependencies returned by declare_dependency, as long as they only specify compiler/linker arguments or other dependencies that satisfy the same requirements.
```
Which is great!

However, there is no warning about doing so even when `meson_version: '>=0.54',` or such. It's pretty easy to accidentally break even just slightly older operating systems like Debian Bullseye. 

Regards,

Andres


Discussion:
You are absolutely correct that this should be tagged with a FeatureNew, which unfortunately may in some cases get forgotten.

I'll look into this tonight if no one beats me to it.

Resolving patch:
diff --git a/mesonbuild/interpreter/compiler.py b/mesonbuild/interpreter/compiler.py
--- a/mesonbuild/interpreter/compiler.py
+++ b/mesonbuild/interpreter/compiler.py
@@ -189,8 +189,7 @@ def __init__(self, compiler: 'Compiler', interpreter: 'Interpreter'):
     def compiler(self) -> 'Compiler':
         return self.held_object
 
-    @staticmethod
-    def _dep_msg(deps: T.List['dependencies.Dependency'], endl: str) -> str:
+    def _dep_msg(self, deps: T.List['dependencies.Dependency'], endl: str) -> str:
         msg_single = 'with dependency {}'
         msg_many = 'with dependencies {}'
         if not deps:
@@ -200,6 +199,8 @@ def _dep_msg(deps: T.List['dependencies.Dependency'], endl: str) -> str:
         names = []
         for d in deps:
             if isinstance(d, dependencies.InternalDependency):
+                FeatureNew.single_use('compiler method "dependencies" kwarg with internal dep', '0.57.0', self.subproject,
+                                      location=self.current_node)
                 continue
             if isinstance(d, dependencies.ExternalLibrary):
                 name = '-l' + d.name


Test patch:
Repository: mesonbuild/meson

Issue:
meson.add_dist_script() in a subproject has MESON_PROJECT_DIST_ROOT == MESON_DIST_ROOT
When project https://gitlab.gnome.org/GNOME/mm-common.git is a subproject,
and meson.add_dist_script() calls a Python script, and that script reads
the environment variable MESON_PROJECT_DIST_ROOT, it's equal to 
MESON_DIST_ROOT, except for the trailing slash.
For instance it's <builddir>/meson-dist/libsigc++-3.0.7/.
Should be <builddir>/meson-dist/libsigc++-3.0.7/subprojects/mm-common.

I haven't seen this behaviour with other projects as subprojects.

To reproduce the error:
```
git clone https://github.com/libsigcplusplus/libsigcplusplus.git
cd libsigcplusplus
meson --wrap-mode=forcefallback _build .
cd _build
meson configure -Dmm-common:use-network=true
ninja
meson dist --include-subprojects --no-tests
```
The dist script subprojects/mm-common/util/meson_aux/extra-dist-cmd.py
does not do what it's supposed to do because MESON_PROJECT_DIST_ROOT points to
the main project instead of subprojects/mm-common.
In the tarball, subprojects/mm-common/ChangeLog should show the latest git commit,
and there should be a subprojects/mm-common/doctags/libstdc++.tag file.

meson.is_subproject() in mm-common's meson.build shows that mm-common is a subproject.

I added some calls to print() in run_dist_scripts() in meson/mesonbuild/mdist.py.
subprojects= {'mm-common': 'subprojects/mm-common'}. All dist scripts have
d.subproject='',  subdir='', even the one that belongs to subprojects/mm-common.

I've tested with meson 0.60.3 and 0.61.99.



Discussion:

Resolving patch:
diff --git a/mesonbuild/interpreter/mesonmain.py b/mesonbuild/interpreter/mesonmain.py
--- a/mesonbuild/interpreter/mesonmain.py
+++ b/mesonbuild/interpreter/mesonmain.py
@@ -87,13 +87,13 @@ def _find_source_script(
             FeatureNew.single_use(f'Passing executable/found program object to script parameter of {name}',
                                   '0.55.0', self.subproject, location=self.current_node)
             largs.append(prog)
-            largs.extend(args)
-            return self.interpreter.backend.get_executable_serialisation(largs)
-        elif isinstance(prog, mesonlib.File):
-            FeatureNew.single_use(f'Passing file object to script parameter of {name}',
-                                  '0.57.0', self.subproject, location=self.current_node)
-        found = self.interpreter.find_program_impl([prog])
-        largs.append(found)
+        else:
+            if isinstance(prog, mesonlib.File):
+                FeatureNew.single_use(f'Passing file object to script parameter of {name}',
+                                      '0.57.0', self.subproject, location=self.current_node)
+            found = self.interpreter.find_program_impl([prog])
+            largs.append(found)
+
         largs.extend(args)
         es = self.interpreter.backend.get_executable_serialisation(largs)
         es.subproject = self.interpreter.subproject


Test patch:
Repository: mesonbuild/meson

Issue:
meson output emits superfluous colon before `compiles:`
Configuring systemd 249 prints:
```
The Meson build system
Version: 0.59.2
Checking if "-Werror=shadow with local shadowing" compiles: YES
```
Configuring systemd 250 prints
```
The Meson build system
Version: 0.61.1
Checking if "-Werror=shadow with local shadowing" : compiles: YES
```
The colon before `compiles` is superfluous.

According to https://github.com/systemd/systemd/issues/22459 this is not caused by systemd, but by meson.


Discussion:

Resolving patch:
diff --git a/mesonbuild/interpreter/compiler.py b/mesonbuild/interpreter/compiler.py
--- a/mesonbuild/interpreter/compiler.py
+++ b/mesonbuild/interpreter/compiler.py
@@ -441,7 +441,7 @@ def compiles_method(self, args: T.Tuple['mesonlib.FileOrString'], kwargs: 'Compi
                 code.rel_to_builddir(self.environment.source_dir))
         testname = kwargs['name']
         extra_args = functools.partial(self._determine_args, kwargs['no_builtin_args'], kwargs['include_directories'], kwargs['args'])
-        deps, msg = self._determine_dependencies(kwargs['dependencies'])
+        deps, msg = self._determine_dependencies(kwargs['dependencies'], endl=None)
         result, cached = self.compiler.compiles(code, self.environment,
                                                 extra_args=extra_args,
                                                 dependencies=deps)


Test patch:
Repository: mesonbuild/meson

Issue:
Unhandled Python exception on meson test --no-rebuild when test executable not built
**Describe the bug**
Unhandled Python exception when running `meson test --no-rebuild` when the test executable is not up to date.

**To Reproduce**

```
echo "project('x','c')"                > meson.build
echo "test('t', executable('missing'))" >> meson.build
meson build
meson test -C build --no-rebuild
....long stack trace....
FileNotFoundError: [Errno 2] No such file or directory: '..../build/missing'

ERROR: Unhandled python exception

    This is a Meson bug and should be reported!
```

**Expected behavior**
Either skip the test with the missing executable, or abort with a tidier error message.

**system parameters**
* Ubuntu 21.10
* Python 3.9.10
* `meson --version 0.61.2`
Check if test executable exists
Resolve #10006


Discussion:

Resolving patch:
diff --git a/mesonbuild/mtest.py b/mesonbuild/mtest.py
--- a/mesonbuild/mtest.py
+++ b/mesonbuild/mtest.py
@@ -1347,9 +1347,12 @@ def __init__(self, test: TestSerialisation, env: T.Dict[str, str], name: str,
             self.console_mode = ConsoleUser.LOGGER
 
     def _get_test_cmd(self) -> T.Optional[T.List[str]]:
-        if self.test.fname[0].endswith('.jar'):
+        testentry = self.test.fname[0]
+        if self.options.no_rebuild and not os.path.isfile(testentry):
+            raise TestException(f'The test program {testentry!r} does not exist. Cannot run tests before building them.')
+        if testentry.endswith('.jar'):
             return ['java', '-jar'] + self.test.fname
-        elif not self.test.is_cross_built and run_with_mono(self.test.fname[0]):
+        elif not self.test.is_cross_built and run_with_mono(testentry):
             return ['mono'] + self.test.fname
         elif self.test.cmd_is_built and self.test.is_cross_built and self.test.needs_exe_wrapper:
             if self.test.exe_wrapper is None:


Test patch:
Repository: mesonbuild/meson

Issue:
java: install jar files to share/java by default



Discussion:
The functionality is something we want but we also want to avoid adding build options that most people don't use. Most projects don't use Java so having this as an unconditional top level option is a bit spammy.

We should come up with some sort of scheme where this is only added if Java is used. Possibly it should be named `java_jardir` or something like that.

Resolving patch:
diff --git a/mesonbuild/build.py b/mesonbuild/build.py
--- a/mesonbuild/build.py
+++ b/mesonbuild/build.py
@@ -2627,6 +2627,9 @@ def get_classpath_args(self):
             return ['-cp', os.pathsep.join(cp_paths)]
         return []
 
+    def get_default_install_dir(self, environment: environment.Environment) -> T.Tuple[str, str]:
+        return environment.get_jar_dir(), '{jardir}'
+
 @dataclass(eq=False)
 class CustomTargetIndex(HoldableObject):
 
diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
--- a/mesonbuild/environment.py
+++ b/mesonbuild/environment.py
@@ -814,6 +814,10 @@ def get_shared_lib_dir(self) -> str:
             return self.get_bindir()
         return self.get_libdir()
 
+    def get_jar_dir(self) -> str:
+        """Install dir for JAR files"""
+        return f"{self.get_datadir()}/java"
+
     def get_static_lib_dir(self) -> str:
         "Install dir for the static library"
         return self.get_libdir()


Test patch:
Repository: mesonbuild/meson

Issue:
install_headers ignores 'subdir:' if 'install_dir:' is set
**Describe the bug**
The install_headers function provides both `install_dir` and `subdir` parameters and documents that the `subdir` parameter is added to any `install_dir` parameter. However, the code ignores `subdir` when `install_dir` is specified.

**To Reproduce**
[install-header.zip](https://github.com/mesonbuild/meson/files/8165005/install-header.zip)

**Expected behavior**
The header file should be installed in install_dir / subdir

**system parameters**
* plain native build
* Debian unstable
* Python 3.9.10
* meson version 0.61.2
* ninja version 1.10.1

**Suggested Fix**
Because existing meson will ignore subdir, I suggest that the documentation be changed to indicate that you cannot use both options at the same time and then make the code raise an error if they are both specified.


Discussion:
Based on a discussion in IRC, where I investigated the implementation in `mesonbuild.backend.backends` and concluded that it probably was not ever intended to support both at the same time. I spot checked version 0.37.0 and the code should be entirely ignoring subdir if install_dir is set, which actually makes sense to me since the purpose of a subdir argument is to work together with the global `--includedir` option.

I think the documentation is just deeply misleading.

However, the implementation doesn't loudly yell at you if you use both, so that's an obvious bug, we should not silently accept a footgun and produce results the user did not expect. :)

Resolving patch:
diff --git a/mesonbuild/interpreter/interpreter.py b/mesonbuild/interpreter/interpreter.py
--- a/mesonbuild/interpreter/interpreter.py
+++ b/mesonbuild/interpreter/interpreter.py
@@ -2004,8 +2004,11 @@ def func_install_headers(self, node: mparser.BaseNode,
                              kwargs: 'kwargs.FuncInstallHeaders') -> build.Headers:
         source_files = self.source_strings_to_files(args[0])
         install_subdir = kwargs['subdir']
-        if install_subdir is not None and os.path.isabs(install_subdir):
-            mlog.deprecation('Subdir keyword must not be an absolute path. This will be a hard error in the next release.')
+        if install_subdir is not None:
+            if kwargs['install_dir'] is not None:
+                raise InterpreterException('install_headers: cannot specify both "install_dir" and "subdir". Use only "install_dir".')
+            if os.path.isabs(install_subdir):
+                mlog.deprecation('Subdir keyword must not be an absolute path. This will be a hard error in the next release.')
 
         h = build.Headers(source_files, install_subdir, kwargs['install_dir'],
                           kwargs['install_mode'], self.subproject)


Test patch: