Added API to manually run CMake by DangMinhTam382 · Pull Request #1483 · eclipse-cdt/cdt

DangMinhTam382 · 2026-06-24T10:57:40Z

Allows ISV to manually run CMake without having to build the project.
Moved code to separate method and make a convenience protected for the derived to call.

github-actions · 2026-06-24T11:01:23Z

Test Results

4 719 tests ±0 4 710 ✅ ±0 2m 42s ⏱️ +9s
183 suites ±0 9 💤 ±0
183 files ±0 0 ❌ ±0

Results for commit 6314dbd. ± Comparison against base commit 90d1dd3.

♻️ This comment has been updated with latest results.

DangMinhTam382 · 2026-06-25T03:53:11Z

Hi Mr. @betamaxbandit ,
CC: Mr. @Kummallinen ,

Before making this PR official, could you take a quick look and let me know what you think?

FYI, it built failed due to the removal of IMG_DLCL_COPY_VIEW_TO_CLIPBOARD in IInternalDebugUIConstants.class.
Fix for this build should be included in #1485

Thanks.

betamaxbandit · 2026-06-25T12:37:09Z

Hi Mr. @betamaxbandit , CC: Mr. @Kummallinen ,

Before making this PR official, could you take a quick look and let me know what you think?

Hi @DangMinhTam382 ,
Thanks for this. I've started reviewing this, but need some more time. I'll probably finish the review tomorrow (Fr).
Cheers John

Allows ISV to manually run CMake without having to build the project. Moved code to separate method and make a convenience protected for the derived to call.

DangMinhTam382 · 2026-07-21T08:31:50Z

Hi Mr. @betamaxbandit ,

I have made some modification to allow manual testing for this PR.
This is now ready to be review now!

Many thanks,
Tam.

betamaxbandit

LGTM, just a few minor grammar issues.

betamaxbandit · 2026-07-21T13:07:54Z


+### 9) CMake configuration
+
+Verifies that API for configuring CMake could work individually.  


Verifies that the API for configuring CMake can be invoked independently.

Thanks for the suggestion! I updated the README.md file

betamaxbandit · 2026-07-21T13:08:38Z

+### 9) CMake configuration
+
+Verifies that API for configuring CMake could work individually.  
+Note, API could only be test in Developer environment with plug-in **org.eclipse.cdt.cmake.example** included.  


Note: this API can only be tested in a CDT development environment that includes the org.eclipse.cdt.cmake.example plug-in.

Thanks for the suggestion! I updated the README.md file

betamaxbandit · 2026-07-21T13:09:40Z

+  1. Remove existing "**/build/**" folder.
+  2. Right click project > select "Configure CMake Project".  
+
+Expected: CMake Configuration process start with active launch settings.


Remove any existing **/build/** folder.

Right-click the project and select Configure CMake Project.

Expected: The CMake configuration process starts using the active launch settings.

Thanks for the suggestion! I updated the README.md file

betamaxbandit · 2026-07-21T15:23:06Z

+	/**
+	 * @since 2.1
+	 */
+	protected IStatus configureCMakeBuildFiles(IProgressMonitor monitor) throws CoreException, IOException {


This helper now refreshes and processes compile_commands.json, but build() continues to do the existing compile_commands.json refresh/processing immediately afterwards. So a normal build that needs to run CMake appears to parse compile_commands.json twice.

Could we split this into two helpers, e.g. one method that only runs the CMake configure command and another that refreshes/processes compile_commands.json? Then build() can keep its existing single compile_commands.json processing step, while the public configure-only API can call both helpers.
Something like ...

private IStatus runCMakeConfigure(CommandDescriptorBuilder cmdBuilder, IConsole console, ConsoleOutputStream infoStream, IProgressMonitor monitor) throws CoreException, IOException { // run CMake only } private void refreshAndProcessCompileCommandsFile(IConsole console, IProgressMonitor monitor) throws CoreException { getCompileCommandsFile().refreshLocal(IResource.DEPTH_ZERO, monitor); processCompileCommandsFile(console, monitor); }

Ahh, you're right there!
It does parse compile_commands.json file twice.

Code updated as your suggestion!

betamaxbandit · 2026-07-21T15:25:02Z

+	 */
+	protected IStatus configureCMakeBuildFiles(IProgressMonitor monitor) throws CoreException, IOException {
+		IProject project = getProject();
+		project.deleteMarkers(ICModelMarker.C_MODEL_PROBLEM_MARKER, false, IResource.DEPTH_INFINITE);


I do not think the configure-only API should delete all CDT problem markers. A manual CMake configure does not run the compiler, so clearing previous compiler diagnostics could hide real errors even though no build has replaced them.

The private helper already clears CMake execution markers via deleteCMakeErrorMarkers(getProject()), which seems appropriate. I suggest removing this broader ICModelMarker.C_MODEL_PROBLEM_MARKER deletion from the configure-only API and leaving broad marker cleanup to the full build path only.

Agreed!
Code updated, no longer remove ICModelMarker.C_MODEL_PROBLEM_MARKER when only configure CMake

betamaxbandit · 2026-07-21T15:48:38Z

+			String arg0 = command.getArguments().get(0);
+			if (p == null) {
+				// process start failed
+				String msg = String.format(Messages.CMakeBuildConfiguration_Failure, ""); //$NON-NLS-1$


Since this message is now returned to callers as an IStatus, it would be useful to include the command that failed to start. Could this use arg0 instead of the empty string?
something like ...

String msg = String.format(Messages.CMakeBuildConfiguration_Failure, arg0);

I had some thought on this one.

Since the condition is checking for process starting error, instead of using arg0, the message is updated to
Failure running cmake: Process failed to start

Error related to arg0 with be check/log in the next condition

if (exitValue != 0) { // cmake had errors... String msg = String.format(Messages.CMakeBuildConfiguration_ExitFailure, arg0, exitValue); addMarker(srcFolder.getProject(), -1, msg, IMarkerGenerator.SEVERITY_ERROR_BUILD, null); return Status.error(msg); }

WDT?

betamaxbandit · 2026-07-21T22:14:05Z


+	/**
+	 * @since 2.1
+	 */


Can you add a good comment seeing as this is going to be API.
Something like ...

/** * Runs the CMake configure step for this build configuration without invoking * the build target. On success, refreshes and processes compile_commands.json * so scanner information is updated. * <p> * This method writes to the CDT build console, deletes stale CMake execution * markers, may create new CMake execution markers, and updates scanner * information for this build configuration. Callers should run this from a * background workspace operation, not directly from the UI thread. * * @param monitor progress monitor, or {@code null} * @return {@link Status#OK_STATUS} if CMake completed successfully; otherwise * an error status if the CMake process could not be started or exited * non-zero * @throws CoreException if workspace refresh, marker handling, or scanner-info * processing fails * @throws IOException if console/process I/O fails * @since 2.1 */ public IStatus configureCMakeBuildFiles(IProgressMonitor monitor) throws CoreException, IOException {

Ahhh, thanks your suggestion.
That's a big help for me.

betamaxbandit · 2026-07-21T22:31:38Z

-						addMarker(srcFolder.getProject(), -1, msg, IMarkerGenerator.SEVERITY_ERROR_BUILD, null);
-						return null;
-					}
+				IStatus result = configureCMakeBuildFiles(cmdBuilder, console, infoStream, monitor);


This helper now refreshes and processes compile_commands.json, but build() continues to do the existing compile_commands.json refresh/processing immediately afterwards. So a normal build that needs to run CMake appears to parse compile_commands.json twice.

Could we split this into two helpers, e.g. one method that only runs the CMake configure command and another that refreshes/processes compile_commands.json? Then build() can keep its existing single compile_commands.json processing step, while the public configure-only API can call both helpers.

Something like ...

private IStatus runCMakeConfigure(CommandDescriptorBuilder cmdBuilder, IConsole console, ConsoleOutputStream infoStream, IProgressMonitor monitor) throws CoreException, IOException { // run CMake only } private void refreshAndProcessCompileCommandsFile(IConsole console, IProgressMonitor monitor) throws CoreException { getCompileCommandsFile().refreshLocal(IResource.DEPTH_ZERO, monitor); processCompileCommandsFile(console, monitor); }

Ahh, you're right there!
It does parse compile_commands.json file twice.

Code updated as your suggestion!

betamaxbandit · 2026-07-21T22:35:38Z

+							ILog.of(ConfigureExtendedCMakeProjectHandler.class)
+									.error("Failed to configure for extended CMake Project", e); //$NON-NLS-1$
+						}
+						return null;


runInWorkspace should return an IStatus. Returning null after logging the exception is risky and means the Jobs framework does not receive a proper failure status.

Could this return the CoreException status, or an error status for IOException?

Something like ...

} catch (CoreException e) { return e.getStatus(); } catch (IOException e) { ILog.of(ConfigureExtendedCMakeProjectHandler.class) .error("Failed to configure for extended CMake Project", e); //$NON-NLS-1$ return Status.error("Failed to configure for extended CMake Project", e); //$NON-NLS-1$ }

Ahh, thanks for pointing this out and the suggestion as well.

I believe the WorkspaceJob does log the error if an error status is return.
So, I grouped them together and return a simple
Status.error(message, exception)

WDT?

betamaxbandit · 2026-07-21T22:35:42Z

+						return null;
+					}
+				};
+				job.schedule();


This job modifies project state: markers, resource refresh, and scanner information. Should it set a scheduling rule before scheduling, probably the project, to avoid running concurrently with other workspace operations on the same project?
Suggestion ...

job.setRule(project); job.schedule();

I'm with you on this one.

I'm not quite sure if there's another WS job running during CMake configuration process, so I'll play it safe here and set rule to it as suggested.

betamaxbandit · 2026-07-21T22:37:46Z

+         point="org.eclipse.ui.commands">
+      <command
+            id="org.eclipse.cdt.cmake.example.configureCMakeProject"
+            name="Configure Extended CMake Project">


The menu label says "Configure CMake Project" but the command name says "Configure Extended CMake Project". Could these be made consistent? Unless "Extended" has a specific meaning here, I suggest using "Configure CMake Project" in both places.

Ah, yes, the initial intent was to allow CMake configuration only for Extended CMake projects.
Later, this was changed to support all CMake projects, and these spots were somehow missed.

Updated the UI and class names to align with the current behavior.

betamaxbandit

Hi,
this is looking really good.
There's a few minor issues that should be resolved please.

DangMinhTam382

Hi Mr. @betamaxbandit ,

I fixed your comments and this should be ready to be reviewed again

Many thanks,
Tam

DangMinhTam382 · 2026-07-22T08:32:40Z


+	/**
+	 * @since 2.1
+	 */


Ahhh, thanks your suggestion.
That's a big help for me.

DangMinhTam382 · 2026-07-22T08:42:38Z

-						addMarker(srcFolder.getProject(), -1, msg, IMarkerGenerator.SEVERITY_ERROR_BUILD, null);
-						return null;
-					}
+				IStatus result = configureCMakeBuildFiles(cmdBuilder, console, infoStream, monitor);


Ahh, you're right there!
It does parse compile_commands.json file twice.

Code updated as your suggestion!

DangMinhTam382 · 2026-07-22T08:53:23Z

+						return null;
+					}
+				};
+				job.schedule();


I'm with you on this one.

I'm not quite sure if there's another WS job running during CMake configuration process, so I'll play it safe here and set rule to it as suggested.

DangMinhTam382 · 2026-07-22T09:03:23Z


+### 9) CMake configuration
+
+Verifies that API for configuring CMake could work individually.  


Thanks for the suggestion! I updated the README.md file

DangMinhTam382 · 2026-07-22T09:03:37Z

+  1. Remove existing "**/build/**" folder.
+  2. Right click project > select "Configure CMake Project".  
+
+Expected: CMake Configuration process start with active launch settings.


Thanks for the suggestion! I updated the README.md file

DangMinhTam382 · 2026-07-22T09:05:22Z

+	 */
+	protected IStatus configureCMakeBuildFiles(IProgressMonitor monitor) throws CoreException, IOException {
+		IProject project = getProject();
+		project.deleteMarkers(ICModelMarker.C_MODEL_PROBLEM_MARKER, false, IResource.DEPTH_INFINITE);


Agreed!
Code updated, no longer remove ICModelMarker.C_MODEL_PROBLEM_MARKER when only configure CMake

DangMinhTam382 · 2026-07-22T09:19:39Z

+			String arg0 = command.getArguments().get(0);
+			if (p == null) {
+				// process start failed
+				String msg = String.format(Messages.CMakeBuildConfiguration_Failure, ""); //$NON-NLS-1$


I had some thought on this one.

Since the condition is checking for process starting error, instead of using arg0, the message is updated to
Failure running cmake: Process failed to start

Error related to arg0 with be check/log in the next condition

if (exitValue != 0) { // cmake had errors... String msg = String.format(Messages.CMakeBuildConfiguration_ExitFailure, arg0, exitValue); addMarker(srcFolder.getProject(), -1, msg, IMarkerGenerator.SEVERITY_ERROR_BUILD, null); return Status.error(msg); }

WDT?

DangMinhTam382 · 2026-07-22T09:24:26Z

+							ILog.of(ConfigureExtendedCMakeProjectHandler.class)
+									.error("Failed to configure for extended CMake Project", e); //$NON-NLS-1$
+						}
+						return null;


Ahh, thanks for pointing this out and the suggestion as well.

I believe the WorkspaceJob does log the error if an error status is return.
So, I grouped them together and return a simple
Status.error(message, exception)

WDT?

DangMinhTam382 · 2026-07-22T09:29:24Z

+         point="org.eclipse.ui.commands">
+      <command
+            id="org.eclipse.cdt.cmake.example.configureCMakeProject"
+            name="Configure Extended CMake Project">


Ah, yes, the initial intent was to allow CMake configuration only for Extended CMake projects.
Later, this was changed to support all CMake projects, and these spots were somehow missed.

Updated the UI and class names to align with the current behavior.

DangMinhTam382 · 2026-07-22T09:33:02Z

+	/**
+	 * @since 2.1
+	 */
+	protected IStatus configureCMakeBuildFiles(IProgressMonitor monitor) throws CoreException, IOException {


Ahh, you're right there!
It does parse compile_commands.json file twice.

Code updated as your suggestion!

DangMinhTam382 force-pushed the CMakeConfigurationWork branch from db124ca to 6b81f27 Compare June 25, 2026 10:56

DangMinhTam382 added 2 commits July 20, 2026 16:33

Added API to manually run CMake

35070b3

Allows ISV to manually run CMake without having to build the project. Moved code to separate method and make a convenience protected for the derived to call.

Add manually to trigger new API for testing

f70ef1b

DangMinhTam382 force-pushed the CMakeConfigurationWork branch from 6b81f27 to f70ef1b Compare July 20, 2026 10:14

Added manual step for testing

c522997

betamaxbandit requested changes Jul 21, 2026

View reviewed changes

jld01 marked this pull request as ready for review July 21, 2026 13:43

betamaxbandit reviewed Jul 21, 2026

View reviewed changes

betamaxbandit requested changes Jul 21, 2026

View reviewed changes

Fixed comments and made some slight modifications

6314dbd

DangMinhTam382 force-pushed the CMakeConfigurationWork branch from a8aa06f to 6314dbd Compare July 22, 2026 09:00

DangMinhTam382 commented Jul 22, 2026

View reviewed changes

Kummallinen requested a review from betamaxbandit July 28, 2026 08:48


		### 9) CMake configuration

		Verifies that API for configuring CMake could work individually.

Uh oh!

Conversation

DangMinhTam382 commented Jun 24, 2026

Uh oh!

github-actions Bot commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

DangMinhTam382 commented Jun 25, 2026

Uh oh!

betamaxbandit commented Jun 25, 2026

Uh oh!

DangMinhTam382 commented Jul 21, 2026

Uh oh!

betamaxbandit left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

betamaxbandit left a comment

Choose a reason for hiding this comment

Uh oh!

DangMinhTam382 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

github-actions Bot commented Jun 24, 2026 •

edited

Loading