Repository: mesonbuild/meson

Issue:
Meson cmake method issue
**Describe the bug**
Meson is failing to import multiple dependencies such as protobuf, the problem was also occuring with cpprestsdk 

**To Reproduce**
```
project('App', 'cpp')

gtkmmdep = dependency('gtkmm-3.0')
protobufdep = dependency('protobuf')
executable('Application', 'src/app.cpp', dependencies : [gtkmmdep, protobufdep], cpp_pch : 'pch/App_pch.h')
```

**Current output**:
```
[0/1] Regenerating build files.
The Meson build system
Version: 0.55.0
Source dir: /home/xxx/Documents/Developpement/App
Build dir: /home/xxx/Documents/Developpement/App/builddir
Build type: native build
Project name: App
Project version: undefined
C++ compiler for the host machine: c++ (gcc 10.1.1 "c++ (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)")
C++ linker for the host machine: c++ ld.bfd 2.34-3
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.6.3)
Found CMake: /usr/local/bin/cmake (3.18.20200725)

../meson.build:3:0: ERROR: CMake: set() requires at least one argument
CMake TRACE: /home/infrandomness/sdk/grpc/lib64/cmake/protobuf/protobuf-config-version.cmake:7 set(['', ''])
```

**Expected behavior**
Meson succeeding at setting protobuf as a dependency and producing a binary with it

**system parameters**
* Is this a [cross build](https://mesonbuild.com/Cross-compilation.html) or just a plain native build (for the same computer)?
Just a plain native build
* what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.)
Fedora 32 5.7.9-200.fc32.x86_64
* what Python version are you using e.g. 3.8.0
Python 3.8.3
* what `meson --version`
0.55.0
* what `ninja --version` if it's a Ninja build
1.10.0


Discussion:
Is this a regression from 0.54?
I doubt it. This "bug" should be present since the early versions of CMake dependencies, judging from the error. The problem is that the CMake trace output doesn't make sense, since the CMake function `set()` is called with two empty strings. There could also be a different underlying issue similar to #7545.

Meson currently configured to error out when something like this happens. I guess we could print a warning instead when faulty CMake code is detected, but the current system works just fine for 99% of the dependencies. 

@InfRandomness what protobuf setup are you using? `/home/infrandomness/sdk/grpc` doesn't look like a standard path and I am unable to reproduce this locally.
Hello, I've followed [this setup](https://grpc.io/docs/languages/cpp/quickstart/) where I compile and install grpc myself into a dir that's in my $PATH variables.

I also tried after this to remove the current installation and variables. I installed grpc and grpc-devel using my package manager (dnf) but it still didn't work.

Resolving patch:
diff --git a/mesonbuild/cmake/traceparser.py b/mesonbuild/cmake/traceparser.py
--- a/mesonbuild/cmake/traceparser.py
+++ b/mesonbuild/cmake/traceparser.py
@@ -74,7 +74,7 @@ def __init__(self, name):
         self.working_dir = None  # type: T.Optional[str]
 
 class CMakeTraceParser:
-    def __init__(self, cmake_version: str, build_dir: str, permissive: bool = False):
+    def __init__(self, cmake_version: str, build_dir: str, permissive: bool = True):
         self.vars = {}     # type: T.Dict[str, T.List[str]]
         self.targets = {}  # type: T.Dict[str, CMakeTarget]
 


Test patch:
diff --git a/test cases/linuxlike/13 cmake dependency/cmake/FindSomethingLikeZLIB.cmake b/test cases/linuxlike/13 cmake dependency/cmake/FindSomethingLikeZLIB.cmake
--- a/test cases/linuxlike/13 cmake dependency/cmake/FindSomethingLikeZLIB.cmake	
+++ b/test cases/linuxlike/13 cmake dependency/cmake/FindSomethingLikeZLIB.cmake	
@@ -4,6 +4,9 @@ include(CMakeFindDependencyMacro)
 include(CheckCXXSourceRuns)
 include(CheckCSourceRuns)
 
+# Do something stupid (see https://github.com/mesonbuild/meson/issues/7501)
+set("")
+
 check_cxx_source_runs(
 "
 #include <iostream>