Build Error from compile commands generator on MBS projects with build location outside workspace

[Kummallinen]

Describe the bug
When building an MBS project that has the build location set to outside of the workspace the build errors with an NPE in CompilationDatabaseGenerator.

!ENTRY org.eclipse.core.resources 4 2 2025-01-20 18:31:28.848
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources".
!STACK 0
java.lang.NullPointerException: Cannot invoke "org.eclipse.core.runtime.IPath.append(String)" because "buildDirectory" is null
	at org.eclipse.cdt.managedbuilder.internal.core.jsoncdb.generator.CompilationDatabaseGenerator.generate(CompilationDatabaseGenerator.java:93)
	at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:515)
	at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:471)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1077)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
	at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:595)
	at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:491)
	at org.eclipse.ui.actions.BuildAction$1.runInWorkspace(BuildAction.java:288)
	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:43)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

To Reproduce
Steps to reproduce the behavior:

1. Create a managed build project
2. Disable Makefile generation & move the build location to a folder outside of the workspace (C/C++Build -> Builder Settings)
3. Run a build

Expected behavior
Should disable compile-commands.json generation when makefile generation is disabled, as the invoked build may not match the MBS settings

[jonahgraham]

AFAICT this only happens if compile_commands.json generation is enabled, so the workaround for anyone affected is to disable the generation manually in preferences:

or in the project properties

@Kummallinen I see you self-assigned, lmk if you want any help with this.

[Kummallinen]

Thanks @jonahgraham, I've asked @alicetrifu to look at this so we can get a fix into CDT 12. Not sure why but I can't assign it to her

[alicetrifu]

Hello @jonahgraham ,

Before proceeding with a fix, I seek your guidance on the optimal approach for generating the CompilationDatabase within the CommonBuilder class. Currently, this generation occurs in the build method:

IProject[] build(int kind, IProject project, IBuilder[] builders, boolean isForeground, IProgressMonitor monitor, MyBoolean isBuild) throws CoreException

To determine if the Makefile generator is active, one approach involves declaring here as well a BuildStatus instance as follows:

BuildStatus status = new BuildStatus(activeCfg.getBuilder());

This instance would then serve as a condition for generating the CompilationDatabase in this place.

Alternatively, we could relocate the generation of the compile_commands.json file to the performPrebuildGeneration method, where information related to the ManagedBuild is already accessible. (Tested this and seems to work fine as well)

In your opinion, which of these solutions would be more efficient and align better with our existing architecture?

Thank you,
Alice

[jonahgraham]

Alternatively, we could relocate the generation of the compile_commands.json file to the performPrebuildGeneration method, where information related to the ManagedBuild is already accessible. (Tested this and seems to work fine as well)

This seems like the better case to me.