6

我在一个项目上工作，它使用“make and gcc”来编译它的所有模块。这些模块位于它们自己的文件夹中，并拥有自己的 Makefile。全局 Makefile 调用它们以编译二进制文件。

所以现在我正在尝试使用 Visual Studio Code 作为我的 IDE。我已经设置了编译环境，它运行良好。

唯一的问题是每当有一些警告/编译时，单击它们不会打开正确的文件。我的工作目录将类似于下面显示的简化代码。

D:\SO
|-- common
|   |-- main.c
|   `-- Makefile
`-- Makefile

从任务中，我将调用外部 Makefile，它将调用内部通用的 Makefile。在 main.c 中，我故意删除了 stdio.h 头文件包含，它应该显示隐式声明错误。但是当我单击问题窗口上的警告时，VS 代码会抛出一个错误，显示该文件未找到。VS Code 尝试打开“D:\SO\main.c”，但文件实际上在“D:\SO\common\main.c”中

在此处输入图像描述

外部 Makefile

all:
    (cd common &&  make )

内部 Makefile（在公共目录内）

all:
    gcc main.c

主程序

int main(int argc, char *argv[])
{
    printf("Hello World");
    return 0;
}

任务.json

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "taskName": "make",
            "command": "make",
            "type": "shell",
            "problemMatcher": [
                "$gcc"
            ]
        }
    ]
}

我试图通过为 fileLocation 参数提供不同的组合来调整问题匹配器。但它们没有产生正确的结果。所以我没有把它包括在这里。

我在带有 mingw-gcc 的 Windows 10 1607 x64 上使用 Visual Studio Code 1.14.2。

4

1 回答 1

1

这不是您问题的答案，但我希望这将是 Microsoft 或其他人可以提供的任何解决方案的先决条件。

您的嵌套 Makefile 中有一个错误。你不应该在 Makefile 中使用这种模式：

cd somewhere; make target

是不必要的cd（见下文），但make直接使用是一个问题。这种模式破坏了一次调用 make 将信息传递给子 make 的能力。特别是，它弄乱了并行制作。它还make使用当前的 shell 路径调用，这可能不是make最初使用的路径。您应该始终使用此模式：

$(MAKE) -C somewhere target

该-C dir参数告诉 make 在哪里设置其当前工作目录。并且 using$(MAKE)允许传递标志和参数。

由于这是推荐的嵌套 Makefile 模式，我认为 vscode 将执行的任何解析以确定适当的fileLocation方式都可能需要它。

于 2018-11-21T20:54:59.937 回答