Makefile using GCC dependency tracking creates erroneous .d file in workspace root

[bhspyder]

Problem

I have a C project with a Makefile that uses mingw gcc to generate dep files during compilation like so:

CC=gcc

SRC_DIR=src
OBJ_DIR=obj
LIB_DIR=lib
BIN_DIR=bin

SOURCES=$(wildcard $(SRC_DIR)/*.c)
OBJECTS=$(SOURCES:$(SRC_DIR)/%.c=$(OBJ_DIR)/%.o)
DEPS=$(OBJECTS:%.o=%.d)
TARGET=$(BIN_DIR)/Program.exe

CC_FLAGS=-Wall -MT $@ -MMD -MP -MF $(@:%.o=%.d)
LD_FLAGS=-L$(LIB_DIR)

all: $(OBJ_DIR) $(BIN_DIR) $(TARGET)

# Link objects
$(TARGET): $(OBJECTS)
	@echo 'Building target: $@'
	@echo 'Invoking: MinGW GCC C Linker'
	$(CC) -o $@ $^ $(LD_FLAGS)
	@echo 'Finished building target: $@'
	@echo ' '

# Compile sources
$(OBJECTS): $(OBJ_DIR)/%.o : $(SRC_DIR)/%.c
	@echo 'Building file: $<'
	@echo 'Invoking: MinFW GCC C Compiler'
	$(CC) $(CC_FLAGS) -c $< -o $@
	@echo 'Finished building: $<'
	@echo ' '

# Ensure required directories exist
$(OBJ_DIR) $(BIN_DIR):
	@echo 'Creating output directory: $<'
	$(MKDIR) $@
	@echo ' '

-include $(DEPS)

This works correctly when building from command-line (make all) or by building the target with the extension in vscode, but for some reason, on the first time opening one of the .c files in my project, a file called nul.d appears in my workspace root containing the following:

obj/Main.o: nul

The contents change with the object filename of the .c file I last opened. It seems like it has something to do with the way IntelliSense is invoking the Makefile, but I haven't been able to reproduce it from the command-line.

If I remove the dep generation flags -MT $@ -MMD -MP -MF $(@:%.o=%.d) the problem does not occur.

Info:

OS: Windows 11 (x64) GCC: 11.2.0 (MinGW-W64 x86_64-ucrt-posix-seh) Make: GNU Make 4.3 (Built for x86_64-w64-mingw32) VSCode: 1.69.2 Makefile Tools: 0.5.0

[andreeis]

@bhspyder, interesting. For IntelliSense, we invoke make with any flags/targets you specify in .vscode/settings.json, plus the following: --dry-run --always-make --keep-going --print-directory. Try to add those and see if you reproduce in command line.

[bhspyder]

I tried to reproduce the issue from the command-line using those flags and it doesn't produce a problem. Whatever is causing it is contextual the .c file I open for display in vscode. Once I've opened the file once, the nul.d file doesn't show up again for that file for the rest of the session. If I close the workspace and reopen it, the problem occurs again.

[andreeis]

@Colengms, does this ring any bells from the CppTools issues collection?

[Colengms]

Hi @andreeis . This appears to be an issue with the C/C++ Extension not excluding (all of) those args when querying the compiler for system includes and system defines. I'll transfer this issue to cpptools.

[sean-mcmanus]

Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.12.1

[bhspyder]

Can confirm that using v1.12.1-2 prerelease resolves the issues on my end. Thanks!