Make does not always work out of the `makeDirectory`

[solidDoWant]

It appears that when performing the dry run, the make invocation always takes place in the workspace folder, even when makeDirectory is set to another directory. The correct makefile ($makeDirectory/Makefile) is executed, but it operates as if the file was in the workspace root. There are some cases where this causes makefile logic to not execute correctly.

In my specific case, I'm writing some Linux kernel modules that are external to the Linux tree. I will probably not attempt to upstream them, so I am not forking the kernel git repo. Instead, I wrote some tooling to clone the kernel tree, and set it up so that it can be used for kernel development. My workspace directory looks like this:

Workspace root
├── Kbuild
├── kernel
│   └── master
│       └── <kernel files>
└── my-module.c

Following the docs, I basically need to run make -C ./kernel/master M=$PWD to build my module. This command works exactly as expected if I run it as a command in a shell with the workspace root as the working directory.

I tried to configure this plugin base on that. However, with this configuration:

{
    "makefile.configurations": [
        {
            "name": "Kernel master branch",
            "makeDirectory": "${workspaceFolder}/kernel/master",
            "makeArgs": [
                "M=${workspaceFolder}",
            ]
        }
    ]
}

I get a bunch of errors and messages logged that heavily indicate that make is operating out of the workspace root. For example, there are logs about files in the makeDirectory not existing when they do exist (as regular files, not symlinks or anything else). Make also reports that some targets don't exist that exist under the kernel tree.

To reproduce:

1. Setup a workspace as outlined above. The path ./kernel/master should contain the kernel source tree (so the kernel's main Makefile should be there). my-module.c can be empty, and Kbuild should contain only obj-m := my-module.o.

2. Install the kernel build requirements. On Ubuntu this will install everything:

   apt update && apt install -y make gcc libssl-dev liblz4-tool expect g++ \
   patchelf chrpath gawk texinfo chrpath diffstat software-properties-common bison \
   flex fakeroot cmake unzip device-tree-compiler libncurses-dev python3-pip \
   python3-pyelftools bc make build-essential libssl-dev zlib1g-dev libbz2-dev \
   libreadline-dev libsqlite3-dev wget curl llvm libncursesw5-dev xz-utils tk-dev \
   libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev python3 rsync python-is-python3

   This is a superset of what's required... sorry. Not sure what exactly is and isn't, but this will work.

3. Build the kernel with cd ./kernel/master && make mrproper && make defconfig && make.
4. Configure the makefile plugin as outlined above, and reload the window to force the plugin to refresh.
5. View the error messages about missing files/targets that are present under the kernel directory.

I'm not entirely certain if 2 and 3 are required, but I know that the issue will occur if they are performed.

It'd be nice if the working directory (not just -C var value) could be set when invoking make. I think that would allow me to work around the issue.

[gcampbell-msft]

If I'm understanding your issue correctly, what you're describing is currently by design in the Makefile Tools extension.

The makeDirectory setting is used to determine what is passed to the command-line with the -C command, but the make.exe invocation always happens in the workspace root.

However, I'm not sure I fully understand your comment here:

"Following the docs, I basically need to run make -C ./kernel/master M=$PWD to build my module. This command works exactly as expected if I run it as a command in a shell with the workspace root as the working directory."

Are you saying that when you run it on the command-line, you DO run it from the workspace root? And it works? But that when the makefile tools extension does the same thing, it doesn't work?

Additionally, are you able to zip up your project and send it to us in a comment on this issue? This would make it easier to reproduce. Lastly, What operating system are you working on? Thanks!

[gcampbell-msft]

@solidDoWant Closing based on last comment. Please follow up by creating a new issue if you find that this is still undesired behavior and not working for you. Thanks!