Repository: mesonbuild/meson

Issue:
All Projects fail to configure on windows with python 3.8 beta
This is strange since the CI for windows appears to be passing.

I have tried to configure a project on windows (even the trivial testcase project) on both my machines, with vs 2019, vs 2019 preview and vs 2019 internal nightly builds and all fail with the error:

```
Traceback (most recent call last):
  File "c:\users\barch\source\repos\meson\mesonbuild\mesonmain.py", line 129, in run
    return options.run_func(options)
  File "c:\users\barch\source\repos\meson\mesonbuild\msetup.py", line 244, in run
    app.generate()
  File "c:\users\barch\source\repos\meson\mesonbuild\msetup.py", line 159, in generate
    self._generate(env)
  File "c:\users\barch\source\repos\meson\mesonbuild\msetup.py", line 214, in _generate
    intr.backend.generate(intr)
  File "c:\users\barch\source\repos\meson\mesonbuild\backend\ninjabackend.py", line 301, in generate
    with self.detect_vs_dep_prefix(tempfilename) as outfile:
  File "c:\users\barch\source\repos\meson\mesonbuild\backend\ninjabackend.py", line 251, in detect_vs_dep_prefix
    pc = subprocess.Popen([compiler.get_exelist(),
  File "c:\users\barch\appdata\local\programs\python\python38\lib\subprocess.py", line 829, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "c:\users\barch\appdata\local\programs\python\python38\lib\subprocess.py", line 1218, in _execute_child
    args = list2cmdline(args)
  File "c:\users\barch\appdata\local\programs\python\python38\lib\subprocess.py", line 524, in list2cmdline
    for arg in map(os.fsdecode, seq):
  File "c:\users\barch\appdata\local\programs\python\python38\lib\os.py", line 815, in fsdecode
    filename = fspath(filename)  # Does type-checking of `filename`.
TypeError: expected str, bytes or os.PathLike object, not list
```
this may be related to #5639 but the fact I get it everywhere indicates perhaps a more critical issue, or a problem with versions of visual studio that are not tested by CI.


Discussion:
Coincidentally I was working with VS2019 by itself, and separately with ICC over the past few days including today on some C / C++ projects with VS2019 and a couple different recent commits on meson master branch. I didn't see any issues.

```
C compiler for the host machine: cl (msvc 19.22.27905)
C linker for the host machine: link 19.22.27905
```

```
C compiler for the host machine: icl (intel-cl 19.1.0.085)
C linker for the host machine: xilink 19.1.0.085
```

```
C compiler for the host machine: cl (msvc 19.22.27905)
C linker for the host machine: link 19.22.27905
```
that's from the x64 native command prompt
meson 0.51.999 (f097b96883a54868cf98600be23893268b5832f4)
python 3.8.0b2
do you have multiple visual studio instances installed?

Where is ninja coming from?
I was also using x64 native command. I have vs2017 installed through the vs2019 installer also. Using Miniconda Python 3.7 installed standalone (not thru  VS). Ninja 1.9 binary was downloaded from GitHub releases and manually put on Path. 
I also can't replicate, I'm using ninja from chocolatey. I have 2015, 2017, and 2019 installed.
Is there a good reason you're using a beta release of Python?
I was working on some python code using the new features of typing. Looks like this bug doesn't happen on python 3.7
It looks like 3.8 would prefer the list passed to `subprocess` be flattened. It may or may not be considered a regression, but it seems easy enough to fix on Meson side.
Here's what I experience, so far still not seeing bug with a few tests tried:
```posh
c:\python38\python --version                                                      
 Python 3.8.0b3
```

then from vs2019 x64 native shell and  f097b96
```posh
c:\python38\python run_project_tests --only common

c      : cl (msvc 19.22.27905)
cpp    : cl (msvc 19.22.27905)

Total passed tests: 214
Total failed tests: 0
Total skipped tests: 9
```

So maybe there is some other distinction we're missing
> It may or may not be considered a regression

It would *definitely* be a Python regression, because passing a list is almost always better than a string because in the latter case you get into quoting/escaping hell.
It's not just a list, it's a nested list.
> It's not just a list, it's a nested list.

Ah, I missed that. Yeah, that's not necessarily a bug. We should fix it.
Is there a specific test case or example that fails. In case it was fixed already  in python 3.8 beta 3
`test cases/common/1 trivial`
OK thanks--I am not able to reproduce the issue here, maybe someone more experienced can. I just tried again with:

* Meson latest master: cf55cd5c9
* Python 3.8 beta 4
* msvc 19.22.27905

Should we do a proactive list flattening with itertools.chain() ?
With Python 3.8 beta 4 and `intel-cl 19.1.0.085` that this error occurs for me as well. I get the same traceback as the original post.  With Python 3.7 I don't get the error.

Resolving patch:
diff --git a/mesonbuild/backend/ninjabackend.py b/mesonbuild/backend/ninjabackend.py
--- a/mesonbuild/backend/ninjabackend.py
+++ b/mesonbuild/backend/ninjabackend.py
@@ -248,8 +248,8 @@ def detect_vs_dep_prefix(self, tempfilename):
         # and locale dependent. Any attempt at converting it to
         # Python strings leads to failure. We _must_ do this detection
         # in raw byte mode and write the result in raw bytes.
-        pc = subprocess.Popen([compiler.get_exelist(),
-                               '/showIncludes', '/c', 'incdetect.c'],
+        pc = subprocess.Popen(compiler.get_exelist() +
+                              ['/showIncludes', '/c', 'incdetect.c'],
                               cwd=self.environment.get_scratch_dir(),
                               stdout=subprocess.PIPE, stderr=subprocess.PIPE)
         (stdout, stderr) = pc.communicate()


Test patch: