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

Issue:
@CURRENT_SOURCE_DIR@ expands to ../ instead of ..
Using meson 0.42.0.

My goals were similar to those in https://github.com/mesonbuild/meson/issues/1622 but my sources are setup as follows:

```
├── meson.build
├── proto
│   ├── myproto.capnp
├── src
└── test
    ├── meson.build
    ├── proto
    │   └── testproto.capnp
    ├── tests-main.cpp
```

and as such, I'd like to create a single `generator` in the top level meson.build:

```
capnproto_gen = generator(capnp,
    output    : ['@PLAINNAME@.c++', '@PLAINNAME@.h'],
    arguments : ['compile', '--src-prefix=@CURRENT_SOURCE_DIR@/proto', '-oc++:@BUILD_DIR@', '@INPUT@']
)
```

However, in the top level build file `@CURRENT_SOURCE_DIR@` expands to `../` (as verified w `ninja -v`) instead of `..`, which creates paths like `--src-prefix=..//proto` which the generator does not accept.

It actually ends up working in the subdir, as it expands to `../test` which happens to work OK.

I tried `arguments : ['compile', '--src-prefix=@0@/proto'.format(meson.current_source_dir()), '-oc++:@BUILD_DIR@', '@INPUT@']` but that doesn't work since the call to `format()` only happens when the top level build file is processed, not at expansion time.


Discussion:
Why can't you remove the slash you added in the string?
because in the subdir that would resolve to `--src-prefix=../testproto` instead of the correct `--src-prefix=../test/proto`.
it's also inconsistent w `@SOURCE_DIR@` which expands to `..` (but of course doesn't work for the subdir).

Resolving patch:
diff --git a/mesonbuild/backend/backends.py b/mesonbuild/backend/backends.py
--- a/mesonbuild/backend/backends.py
+++ b/mesonbuild/backend/backends.py
@@ -156,8 +156,11 @@ def get_target_dir(self, target):
         return dirname
 
     def get_target_source_dir(self, target):
-        dirname = os.path.join(self.build_to_src, self.get_target_dir(target))
-        return dirname
+        # if target dir is empty, avoid extraneous trailing / from os.path.join()
+        target_dir = self.get_target_dir(target)
+        if target_dir:
+            return os.path.join(self.build_to_src, target_dir)
+        return self.build_to_src
 
     def get_target_private_dir(self, target):
         dirname = os.path.join(self.get_target_dir(target), target.get_basename() + target.type_suffix())


Test patch:
Repository: mesonbuild/meson

Issue:
install_man encodes timestamps (causes non-reproducible builds)
While packaging `fuse 3.2.0` for Nix(OS) I noticed that the build became non-reproducible after the switch to meson. With the help of `diffoscope` I discovered that it was due to timestamps inside the metatdata fields of gzip compressed man pages.

It's caused by `gzip.compress()`: https://github.com/mesonbuild/meson/blob/c63aa0372b7acd8f6a094ca240eb39c8aab646cf/mesonbuild/scripts/meson_install.py#L230

A possible fix would be to explicitly set `mtime=0` like here: https://stackoverflow.com/a/36034315

> The mtime argument is an optional numeric timestamp to be written to the stream when compressing. All gzip compressed streams are required to contain a timestamp. If omitted or None, the current time is used. This module ignores the timestamp when decompressing; however, some programs, such as gunzip, make use of it. The format of the timestamp is the same as that of the return value of time.time() and of the st_mtime attribute of the object returned by os.stat().
-- https://docs.python.org/2/library/gzip.html

Example from fuse3:
```
├── share
│ ├── man
│ │ ├── man1
│ │ │ ├── fusermount3.1.gz
│ │ │ │ ├── metadata
│ │ │ │ │ @@ -1 +1 @@
│ │ │ │ │ -gzip compressed data, from Unix
│ │ │ │ │ +gzip compressed data, last modified: Thu Sep 21 21:58:10 2017, max compression
│ │ ├── man8
│ │ │ ├── mount.fuse.8.gz
│ │ │ │ ├── metadata
│ │ │ │ │ @@ -1 +1 @@
│ │ │ │ │ -gzip compressed data, from Unix
│ │ │ │ │ +gzip compressed data, last modified: Thu Sep 21 21:58:10 2017, max compression
```


Discussion:

Resolving patch:
diff --git a/mesonbuild/scripts/meson_install.py b/mesonbuild/scripts/meson_install.py
--- a/mesonbuild/scripts/meson_install.py
+++ b/mesonbuild/scripts/meson_install.py
@@ -227,7 +227,9 @@ def install_man(d):
         if outfilename.endswith('.gz') and not full_source_filename.endswith('.gz'):
             with open(outfilename, 'wb') as of:
                 with open(full_source_filename, 'rb') as sf:
-                    of.write(gzip.compress(sf.read()))
+                    # Set mtime and filename for reproducibility.
+                    with gzip.GzipFile(fileobj=of, mode='wb', filename='', mtime=0) as gz:
+                        gz.write(sf.read())
             shutil.copystat(full_source_filename, outfilename)
             append_to_log(outfilename)
         else:


Test patch:
Repository: mesonbuild/meson

Issue:
missing runtime vcruntime140.dll 
Hi thanks for your great project ! I installed **meson-0.42.1-32.msi** on a mostly clean 32-bit Windows 7, then on launching `meson --version` in a cmd, I get the "missing runtime vcruntime140.dll " pop-up.

To fix it, I installed the [Microsoft Visual C++ 2015 Redistributable](https://www.microsoft.com/en-US/download/details.aspx?id=53587), this should probably be documented.


Discussion:
We should distribute that with the MSI, ideally. We can start doing that with the next release.
http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_vcredist.html

Resolving patch:
diff --git a/msi/createmsi.py b/msi/createmsi.py
--- a/msi/createmsi.py
+++ b/msi/createmsi.py
@@ -47,8 +47,10 @@ def __init__(self):
         self.staging_dirs = ['dist', 'dist2']
         if self.bytesize == 64:
             self.progfile_dir = 'ProgramFiles64Folder'
+            self.redist_path = 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Redist\\MSVC\\14.11.25325\\MergeModules\\Microsoft_VC141_CRT_x64.msm'
         else:
             self.progfile_dir = 'ProgramFilesFolder'
+            self.redist_path = 'c:\\Program Files\\Microsoft Visual Studio\\2017\\Community\\VC\\Redist\\MSVC\\14.11.25325\\MergeModules\\Microsoft_VC141_CRT_x86.msm'
         self.component_num = 0
         self.feature_properties = {
             self.staging_dirs[0]: {
@@ -141,6 +143,12 @@ def generate_files(self):
             'Id': 'INSTALLDIR',
             'Name': 'Meson',
         })
+        ET.SubElement(installdir, 'Merge', {
+            'Id': 'VCRedist',
+            'SourceFile': self.redist_path,
+            'DiskId': '1',
+            'Language': '0',
+            })
 
         ET.SubElement(product, 'Property', {
             'Id': 'WIXUI_INSTALLDIR',
@@ -166,6 +174,14 @@ def generate_files(self):
                 nodes[root] = cur_node
             self.create_xml(nodes, sd, installdir, sd)
             self.build_features(nodes, top_feature, sd)
+        vcredist_feature = ET.SubElement(top_feature, 'Feature', {
+            'Id': 'VCRedist',
+            'Title': 'Visual C++ runtime',
+            'AllowAdvertise': 'no',
+            'Display': 'hidden',
+            'Level': '1',
+            })
+        ET.SubElement(vcredist_feature, 'MergeRef', {'Id': 'VCRedist'})
         ET.ElementTree(self.root).write(self.main_xml, encoding='utf-8', xml_declaration=True)
         # ElementTree can not do prettyprinting so do it manually
         import xml.dom.minidom


Test patch:
Repository: mesonbuild/meson

Issue:
Upgraded to meson 0.43.0 and now boost program-options is not a valid boost library
```
boost   = dependency ('boost',
                        modules : [ 'thread', 'filesystem',
                                    'program_options', 'log_setup',
                                    'log', 'date_time', 'system' ])
```

error:

```
Meson encountered an error in file meson.build, line 23, column 0:
Dependency program_options not found. It is not a valid boost library.
```

the program no longer links, since it is missing a bunch of references.

Boost package list on Arch Linux: https://gist.github.com/gauteh/205bcdf30d7eda628264e4eb8f4a8bd6


Discussion:

Resolving patch:
diff --git a/mesonbuild/dependencies/misc.py b/mesonbuild/dependencies/misc.py
--- a/mesonbuild/dependencies/misc.py
+++ b/mesonbuild/dependencies/misc.py
@@ -814,6 +814,7 @@ def get_methods(self):
     'boost_math_c99f',
     'boost_math_c99l',
     'boost_mpi',
+    'boost_program_options',
     'boost_random',
     'boost_regex',
     'boost_serialization',
diff --git a/tools/boost_names.py b/tools/boost_names.py
--- a/tools/boost_names.py
+++ b/tools/boost_names.py
@@ -99,6 +99,10 @@ def get_library_names(jamfile):
         for matches in res:
             if ':' in matches.group(2):
                 libs.append(matches.group(1))
+        res = re.finditer(r'^boost-lib[\s]+([A-Za-z0-9_]+)([^;]*);', jam, re.MULTILINE | re.DOTALL)
+        for matches in res:
+            if ':' in matches.group(2):
+                libs.append('boost_{}'.format(matches.group(1)))
     return libs
 
 def exists(modules, module):


Test patch:
Repository: mesonbuild/meson

Issue:
MSI installed meson fails to rerun in visual studio
Initially, I ran `meson build` from the source code directory `xxx` to create the build directory.
Later, if any `meson.build` files are modified, Visual studio fails to rerun Meson with the backtrace below. Meson is installed with MSI. It works with ninja as backend. It also works if meson isn't installed with MSI.

It seems like `mesonscript` in `regen_checker` is invalid when meson is installed with MSI.

```
>meson.exe : error : unrecognized arguments: --internal regenerate C:\Users\niklas\Documents\git\xxx C:\Users\niklas\Documents\git\xxx
1>  Traceback (most recent call last):
1>    File "C:\Users\niklas\AppData\Local\Programs\Python\Python36-32\lib\site-packages\cx_Freeze\initscripts\__startup__.py", line 14, in run
1>      module.run()
1>    File "C:\Users\niklas\AppData\Local\Programs\Python\Python36-32\lib\site-packages\cx_Freeze\initscripts\Console.py", line 26, in run
1>      exec(code, m.__dict__)
1>    File "meson.py", line 37, in <module>
1>    File "meson.py", line 34, in main
1>    File "mesonbuild\mesonmain.py", line 311, in run
1>    File "mesonbuild\mesonmain.py", line 278, in run_script_command
1>    File "mesonbuild\scripts\regen_checker.py", line 56, in run
1>    File "mesonbuild\scripts\regen_checker.py", line 42, in regen
1>    File "C:\Users\niklas\AppData\Local\Programs\Python\Python36-32\lib\subprocess.py", line 291, in check_call
1>      raise CalledProcessError(retcode, cmd)
1>  subprocess.CalledProcessError: Command '['C:\\Program Files\\Meson\\meson.exe', 'C:\\Users\\niklas\\Documents\\git\\xxx\\meson', '--internal', 'regenerate', 'C:\\Users\\niklas\\Documents\\git\\xxx\\build', 'C:\\Users\\niklas\\Documents\\git\\xxx', '--backend=vs2015']' returned non-zero exit status 2.
```


Discussion:

Resolving patch:
diff --git a/mesonbuild/scripts/regen_checker.py b/mesonbuild/scripts/regen_checker.py
--- a/mesonbuild/scripts/regen_checker.py
+++ b/mesonbuild/scripts/regen_checker.py
@@ -32,9 +32,11 @@ def need_regen(regeninfo, regen_timestamp):
     return False
 
 def regen(regeninfo, mesonscript, backend):
-    cmd = [sys.executable,
-           mesonscript,
-           '--internal',
+    if sys.executable.lower().endswith('meson.exe'):
+        cmd_exe = [sys.executable]
+    else:
+        cmd_exe = [sys.executable, mesonscript]
+    cmd = cmd_exe + ['--internal',
            'regenerate',
            regeninfo.build_dir,
            regeninfo.source_dir,


Test patch:
Repository: mesonbuild/meson

Issue:
subproject('../../foo') escapes the current source directory and writes directories outside of the builddir
I tried to use subproject() to depend on two projects outside of project folder with `subproject('../../foo')`. Everything went well with `--layout flat`, besides that meson still creates `subproject` directory tree with only empty directories in the build dir. Since I used `subproject('../../foo')` this result in empty directories being created outside of build dir. Are these empty subproject directories necessory? Or perhaps may be removed under `--layout flat`?


Discussion:
Uh, we should never allow people to escape the subprojects directory by using a leading `'..'`. That is definitely a bug. Please use symlinks inside `subprojects/` if you really want to use directories outside your source tree.
Thank you for reminding me to use symlinks! That solved my problem.
@nirbheek can i work on this?
@narendravardi sure! You should be able to work on any issue with an `easy` tag. If it turns out to not be an easy issue, do tell me so I can remove that tag since it's only an estimate. :)

In this case what you want to do is to run `os.path.normpath` on the argument to `subproject()` and error out if the resulting path starts with `../`.
@nirbheek, making changes to func_subproject() function in interpreter.py file.
Raising InvalidArguments with "Subproject name should not start with ../"
Please let me know if this is correct.
A better check would be to prohibit both `/` and `\` in the subproject name.

Resolving patch:
diff --git a/mesonbuild/interpreter.py b/mesonbuild/interpreter.py
--- a/mesonbuild/interpreter.py
+++ b/mesonbuild/interpreter.py
@@ -1663,6 +1663,8 @@ def func_subproject(self, nodes, args, kwargs):
         return self.do_subproject(dirname, kwargs)
 
     def do_subproject(self, dirname, kwargs):
+        if '/' in dirname or '\\' in dirname:
+            raise InterpreterException('Subproject name must not contain a path separator.')
         if dirname in self.subproject_stack:
             fullstack = self.subproject_stack + [dirname]
             incpath = ' => '.join(fullstack)


Test patch:
Repository: mesonbuild/meson

Issue:
Linker error while building gtkdoc
I'm trying to make GStreamer modules build with meson inside Cerbero. When it builds gtkdoc I get this error:

```
Error in gtkdoc helper script:
'gtkdoc-scangobj' failed with status 1
ld: unrecognized option '-Wl,-rpath,/home/xclaesse/programmation/cerbero/build/sources/linux_x86_64/gst-transcoder-1.9/cerbero-build-dir/'
ld: use the --help option for usage information
Linking of scanner failed: 
```

The exact command line that produce that error is:

```
gtkdoc-scangobj --types=/home/xclaesse/programmation/cerbero/build/sources/linux_x86_64/gst-transcoder-1.9/cerbero-build-dir/docs/libs/gst-transcoder.types --module=gst-transcoder --cflags="-I/home/xclaesse/programmation/cerbero/build/sources/linux_x86_64/gst-transcoder-1.9/cerbero-build-dir/gst-libs -I/home/xclaesse/programmation/cerbero/build/sources/linux_x86_64/gst-transcoder-1.9/gst-libs -I/home/xclaesse/programmation/cerbero/build/dist/linux_x86_64/include/glib-2.0 -I/home/xclaesse/programmation/cerbero/build/dist/linux_x86_64/lib/glib-2.0/include -pthread -I/home/xclaesse/programmation/cerbero/build/dist/linux_x86_64/include/gstreamer-1.0" --ldflags="-L/home/xclaesse/programmation/cerbero/build/sources/linux_x86_64/gst-transcoder-1.9/cerbero-build-dir/ -Wl,-rpath,/home/xclaesse/programmation/cerbero/build/sources/linux_x86_64/gst-transcoder-1.9/cerbero-build-dir/ -lgsttranscoder-1.0 -L/home/xclaesse/programmation/cerbero/build/dist/linux_x86_64/lib -lglib-2.0 -lgobject-2.0 -lgstreamer-1.0 -lgstpbutils-1.0"
```

GStreamer's gtkdoc seems to build fine with meson when using gst-build, so I don't understand what's the difference when ran inside cerbero env.

Any clue?


Discussion:
Ohh, digging code in gtkdoc-scangobj, those ldflags are passed to "ld" binary and not "gcc" so `-Wl,-rpath,/foo` should be translated to `-rpath=/foo` I think. Right?
I got it! cerbero sets `LD=ld` in its env so gtkdoc-scangobj uses it instead of fallbacking to gcc.

Resolving patch:
diff --git a/mesonbuild/scripts/gtkdochelper.py b/mesonbuild/scripts/gtkdochelper.py
--- a/mesonbuild/scripts/gtkdochelper.py
+++ b/mesonbuild/scripts/gtkdochelper.py
@@ -112,7 +112,8 @@ def build_gtkdoc(source_root, build_root, doc_subdir, src_subdirs,
         scanobjs_cmd = ['gtkdoc-scangobj'] + scanobjs_args + ['--types=' + gobject_typesfile,
                                                               '--module=' + module,
                                                               '--cflags=' + cflags,
-                                                              '--ldflags=' + ldflags]
+                                                              '--ldflags=' + ldflags,
+                                                              '--ld=' + ld]
 
         gtkdoc_run_check(scanobjs_cmd, abs_out)
 


Test patch:
Repository: mesonbuild/meson

Issue:
-Db_sanitize=address,undefined doesn't add -fno-omit-frame-pointer
Hi,

```python
def sanitizer_compile_args(value):
    if value == 'none':
        return []
    args = ['-fsanitize=' + value]
    if value == 'address':
        args.append('-fno-omit-frame-pointer')
    return args
```

I just noticed that setting `-Db_sanitize=address,undefined` didn't also set `-fno-omit-frame-pointer` for the compile.

I believe by not having this, it causes both ubsan and asan to not have good stack traces.


Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers/compilers.py b/mesonbuild/compilers/compilers.py
--- a/mesonbuild/compilers/compilers.py
+++ b/mesonbuild/compilers/compilers.py
@@ -273,7 +273,7 @@ def sanitizer_compile_args(value):
     if value == 'none':
         return []
     args = ['-fsanitize=' + value]
-    if value == 'address':
+    if 'address' in value: # For -fsanitize=address,undefined
         args.append('-fno-omit-frame-pointer')
     return args
 


Test patch:
Repository: mesonbuild/meson

Issue:
Running a script as part of project() broken 1b0048a7022a89f461cf4d01e7cdbf995bab70f5
~~I noticed that cross compiling broke in master and bisected it back to this commit. I'm working on a fix now, but wanted to make sure that his was flagged so a release wasn't made with a serious regression.~~

Turns out the real regression is using a `run_command` as part of `project`. Still a problem for mesa though.


Discussion:

Resolving patch:
diff --git a/mesonbuild/interpreter.py b/mesonbuild/interpreter.py
--- a/mesonbuild/interpreter.py
+++ b/mesonbuild/interpreter.py
@@ -1391,6 +1391,8 @@ def __init__(self, build, backend, subproject='', subdir='', subproject_dir='sub
         self.subproject_stack = []
         self.default_project_options = default_project_options[:] # Passed from the outside, only used in subprojects.
         self.build_func_dict()
+        # build_def_files needs to be defined before parse_project is called
+        self.build_def_files = [os.path.join(self.subdir, environment.build_filename)]
         self.parse_project()
         self.builtin['build_machine'] = BuildMachine(self.coredata.compilers)
         if not self.build.environment.is_cross_build():
@@ -1406,7 +1408,6 @@ def __init__(self, build, backend, subproject='', subdir='', subproject_dir='sub
                 self.builtin['target_machine'] = CrossMachineInfo(cross_info.config['target_machine'])
             else:
                 self.builtin['target_machine'] = self.builtin['host_machine']
-        self.build_def_files = [os.path.join(self.subdir, environment.build_filename)]
 
     def build_func_dict(self):
         self.funcs.update({'add_global_arguments': self.func_add_global_arguments,


Test patch:
Repository: mesonbuild/meson

Issue:
RPATH is prefixed with a colon
I'm using `build_rpath : '$ORIGIN/lib'` and it works fine but objdump shows `RUNPATH              :$ORIGIN/lib` The colon should not be there.

Also, lddtree from pax-utils says:
`scanelf: rpath_security_checks(): Security problem NULL DT_RUNPATH in ./binary` (where binary is my program name)

Probably worth a fix [here](https://github.com/mesonbuild/meson/blob/6d85e10df921c0399adfc01507a76f04c684245c/mesonbuild/compilers/compilers.py#L836).


Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers/compilers.py b/mesonbuild/compilers/compilers.py
--- a/mesonbuild/compilers/compilers.py
+++ b/mesonbuild/compilers/compilers.py
@@ -833,7 +833,9 @@ def build_unix_rpath_args(self, build_dir, from_dir, rpath_paths, build_rpath, i
         paths = ':'.join([os.path.join('$ORIGIN', p) for p in rel_rpaths])
         # Build_rpath is used as-is (it is usually absolute).
         if build_rpath != '':
-            paths += ':' + build_rpath
+            if paths != '':
+                paths += ':'
+            paths += build_rpath
         if len(paths) < len(install_rpath):
             padding = 'X' * (len(install_rpath) - len(paths))
             if not paths:


Test patch:
Repository: mesonbuild/meson

Issue:
File not found with rules calling meson --internal
Commit d882b6fbd466940d452cfaa890bd9270e10a93b4 introduced a regression caught by the GNOME Continuous integration builder.

While building a project, in this case libinput, after that commit, the process would stop with this error:

```
FAILED: input@sha/libinput.so.10.13.0.symbols 
/usr/bin/python3 /usr/lib/python3.5/site-packages/mesonbuild/../meson.py --internal symbolextractor libinput.so.10.13.0 'input@sha/libinput.so.10.13.0.symbols' 
/usr/bin/python3: can't open file '/usr/lib/python3.5/site-packages/mesonbuild/../meson.py': [Errno 2] No such file or directory
ninja: build stopped: subcommand failed.
```

Full build log available [here](http://build.gnome.org/continuous/buildmaster/builds/2017/11/21/60/build/log-libinput.txt).


Discussion:
The build log of Meson for that commit is available [here](http://build.gnome.org/continuous/buildmaster/builds/2017/11/21/60/build/log-meson.txt).

Resolving patch:
diff --git a/mesonbuild/mesonlib.py b/mesonbuild/mesonlib.py
--- a/mesonbuild/mesonlib.py
+++ b/mesonbuild/mesonlib.py
@@ -22,13 +22,35 @@
 
 from glob import glob
 
+def detect_meson_py_location():
+    c = sys.argv[0]
+    c_fname = os.path.split(c)[1]
+    if c_fname == 'meson' or c_fname == 'meson.py':
+        # $ /foo/meson.py <args>
+        if os.path.isabs(c):
+            return c
+        # $ meson <args> (gets run from /usr/bin/meson)
+        in_path_exe = shutil.which(c_fname)
+        if in_path_exe:
+            return in_path_exe
+        # $ python3 ./meson.py <args>
+        if os.path.exists(c):
+            return os.path.join(os.getcwd(), c)
+
+    # The only thing remaining is to try to find the bundled executable and
+    # pray distro packagers have not moved it.
+    fname = os.path.join(os.path.dirname(__file__), '..', 'meson.py')
+    if not os.path.exists(fname):
+        raise RuntimeError('Could not determine how to run Meson. Please file a bug with details.')
+    return fname
+
 if os.path.basename(sys.executable) == 'meson.exe':
     # In Windows and using the MSI installed executable.
     meson_command = [sys.executable]
     python_command = [sys.executable, 'runpython']
 else:
-    meson_command = [sys.executable, os.path.join(os.path.dirname(__file__), '..', 'meson.py')]
     python_command = [sys.executable]
+    meson_command = python_command + [detect_meson_py_location()]
 
 
 # Put this in objects that should not get dumped to pickle files


Test patch: