CDT CMake Improvements #1000

betamaxbandit · 2025-01-14T10:24:16Z

The document* describes a number of bug fixes and enhancements to CMake support.

20250226CDT+CMake+Improvements.pdf

Items in the "API Breaking" column marked Yes are planned to be added to CDT 12.

*: formatting is affected by exporting from internal document management system.

For ISV integration/extension to CDT CMake, it is necessary to extend several non-API classes (eg: CMakeBuildConfiguration, CMakeBuildConfigurationProvider). This would cause "Discouraged access: The type XXX is not API" warnings. The classes have now been made API so can be extended without warnings. Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-017 Extending CMakeBuildConfiguration

For ISV integration/extension to CDT CMake, it is necessary to extend several non-API classes (eg: CMakeBuildConfiguration, CMakeBuildConfigurationProvider). This would cause "Discouraged access: The type XXX is not API" warnings. The classes have now been made API so can be extended without warnings. Addresses Issue: CDT CMake Improvements #1000, IDE-82683-REQ-017 Extending CMakeBuildConfiguration

ISV can set their desired CMake generator default (eg Ninja). Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-012 CMake generator default

In issue eclipse-cdt#1000 a lot of the work is on exposing a better API to ISVs. This new project serves these purposes: - Ensure the exposed API works in practice - Example for ISVs to use if they want to extend CMake - Provide an in-tree example of the API in use, so future editors of CDT have better chance of understanding *why* items are done as they are.

ISV can set their desired CMake generator default (eg Ninja). Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-012 CMake generator default

In issue #1000 a lot of the work is on exposing a better API to ISVs. This new project serves these purposes: - Ensure the exposed API works in practice - Example for ISVs to use if they want to extend CMake - Provide an in-tree example of the API in use, so future editors of CDT have better chance of understanding *why* items are done as they are.

ISV can set their desired CMake generator default (eg Ninja). Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-012 CMake generator default

Add support for all generators to CMake build settings Correct command line option for CMake's --warn-unused-vars Rename clean command to clean target to better reflect its use as the argument passed to cmake's --target command line. Add all target for the argument passed to cmake's --target command line when doing a normal build. Clarify usage of UI overrides and change the UI to be "use defaults" (i.e. invert the checkbox). This is a **breaking** change as it means user projects that were using UI overrides will revert to using defaults. This is done on purpose as so many little things have changed in CMake settings, that reverting to defaults on upgrade seems like a logical decision. In addition *use defaults* matches the other GUIs in Eclipse, for example the MBS build command settings. Populate all default in getDefaultProperties() so that all CMake build settings are displayed as used (greyed out) and can be used as a starting point when editing settings. Simplify some of the code in CMakeBuildTab, especially: - removing the duplicated code between initializeFrom and restoreProperties - use Map's getOrDefault instead of a get, followed by a null check. Remove getUseDefaultCommand/setUseDefaultCommand as they don't appear in the GUI and it makes it impossible for the GUI command to be used. It is also redundant as use ui overrides is a global use default for all settings, so having a second use default seems unneeded at this point. Cleanup and simplify getCMakeProperties. Fix parsing of extra args so that quoted strings work. Remove doubled-up extra args added to command line. Refactored manual tests document and brought it up to date. Fixes eclipse-cdt#1055 Part of eclipse-cdt#1000

Adding UI into CMake Preference page that allow user to specify the location of the CMake tool and the location of CMake generators. Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-004 and IDE-82683-REQ-005

Summary: - Add some new API to make it easier for ISVs to provide defaults. - Fully connect UI elements to CMake build process - Add some missing UI elements (such as customizing generator) - CMake generator default within CDT changed to Ninja Details: Add API to set CMake generator default (eg Ninja) ISV can set their desired CMake generator by overriding `CMakeBuildConfiguration.getDefaultProperties`. ISVs can also further fine tune the build process by overriding `CMakeBuildConfiguration.getDefaultProperties` Remove API `IOsOverrides` and related code. `IOsOverrides` was a partial implementation to achieve builds in Docker containers, however the work was not complete and it the extra code was complicating some basic use cases of setting defaults Add support for all generators to CMake build settings UI page by using a Combo instead of radio buttons. The non-deprecated generators that are built-in to CDT populate the Combo, but additional generators can be manually entered in the Combo. Rename clean command to clean target to better reflect its use as the argument passed to cmake's --target command line. Add all target for the argument passed to cmake's --target command line when doing a normal build. Clarify usage of UI overrides and change the UI to be "use defaults" (i.e. invert the checkbox). This is a **breaking** change as it means user projects that were using UI overrides will revert to using defaults. This is done on purpose as so many little things have changed in CMake settings, that reverting to defaults on upgrade seems like a logical decision. In addition *use defaults* matches the other GUIs in Eclipse, for example the MBS build command settings. Populate all defaults in getDefaultProperties() so that all CMake build settings are displayed as used (greyed out) and can be used as a starting point when editing settings. Simplify some of the code in CMakeBuildTab. Fix parsing of extra args so that quoted strings work. Refactored manual tests document and brought it up to date. Correct command line option for CMake's --warn-unused-vars Correct command line option for CMake's --warn-uninitialized Overall this is an API breaking change and the CHANGELOG-API.md has been updated with all the API changes in and around ICMakeProperties, including fixing typos in WarnUninitialized methods. Fixes eclipse-cdt#1055 Part of eclipse-cdt#1000 Co-authored-by: John Moule <[email protected]> Co-authored-by: Jonah Graham <[email protected]>

Summary: - Add some new API to make it easier for ISVs to provide defaults. - Fully connect UI elements to CMake build process - Add some missing UI elements (such as customizing generator) - CMake generator default within CDT changed to Ninja Details: Add API to set CMake generator default (eg Ninja) ISV can set their desired CMake generator by overriding `CMakeBuildConfiguration.getDefaultProperties`. ISVs can also further fine tune the build process by overriding `CMakeBuildConfiguration.getDefaultProperties` Remove API `IOsOverrides` and related code. `IOsOverrides` was a partial implementation to achieve builds in Docker containers, however the work was not complete and it the extra code was complicating some basic use cases of setting defaults Add support for all generators to CMake build settings UI page by using a Combo instead of radio buttons. The non-deprecated generators that are built-in to CDT populate the Combo, but additional generators can be manually entered in the Combo. Rename clean command to clean target to better reflect its use as the argument passed to cmake's --target command line. Add all target for the argument passed to cmake's --target command line when doing a normal build. Clarify usage of UI overrides and change the UI to be "use defaults" (i.e. invert the checkbox). This is a **breaking** change as it means user projects that were using UI overrides will revert to using defaults. This is done on purpose as so many little things have changed in CMake settings, that reverting to defaults on upgrade seems like a logical decision. In addition *use defaults* matches the other GUIs in Eclipse, for example the MBS build command settings. Populate all defaults in getDefaultProperties() so that all CMake build settings are displayed as used (greyed out) and can be used as a starting point when editing settings. Simplify some of the code in CMakeBuildTab. Fix parsing of extra args so that quoted strings work. Refactored manual tests document and brought it up to date. Correct command line option for CMake's --warn-unused-vars Correct command line option for CMake's --warn-uninitialized Overall this is an API breaking change and the CHANGELOG-API.md has been updated with all the API changes in and around ICMakeProperties, including fixing typos in WarnUninitialized methods. Fixes eclipse-cdt#1055 Fixes eclipse-cdt#818 Part of eclipse-cdt#1000 Co-authored-by: John Moule <[email protected]> Co-authored-by: Jonah Graham <[email protected]>

Summary: - Add some new API to make it easier for ISVs to provide defaults. - Fully connect UI elements to CMake build process - Add some missing UI elements (such as customizing generator) - CMake generator default within CDT changed to Ninja Details: Add API to set CMake generator default (eg Ninja) ISV can set their desired CMake generator by overriding `CMakeBuildConfiguration.getDefaultProperties`. ISVs can also further fine tune the build process by overriding `CMakeBuildConfiguration.getDefaultProperties` Remove API `IOsOverrides` and related code. `IOsOverrides` was a partial implementation to achieve builds in Docker containers, however the work was not complete and it the extra code was complicating some basic use cases of setting defaults Add support for all generators to CMake build settings UI page by using a Combo instead of radio buttons. The non-deprecated generators that are built-in to CDT populate the Combo, but additional generators can be manually entered in the Combo. Rename clean command to clean target to better reflect its use as the argument passed to cmake's --target command line. Add all target for the argument passed to cmake's --target command line when doing a normal build. Clarify usage of UI overrides and change the UI to be "use defaults" (i.e. invert the checkbox). This is a **breaking** change as it means user projects that were using UI overrides will revert to using defaults. This is done on purpose as so many little things have changed in CMake settings, that reverting to defaults on upgrade seems like a logical decision. In addition *use defaults* matches the other GUIs in Eclipse, for example the MBS build command settings. Populate all defaults in getDefaultProperties() so that all CMake build settings are displayed as used (greyed out) and can be used as a starting point when editing settings. Simplify some of the code in CMakeBuildTab. Fix parsing of extra args so that quoted strings work. Refactored manual tests document and brought it up to date. Correct command line option for CMake's --warn-unused-vars Correct command line option for CMake's --warn-uninitialized Overall this is an API breaking change and the CHANGELOG-API.md has been updated with all the API changes in and around ICMakeProperties, including fixing typos in WarnUninitialized methods. Fixes #1055 Fixes #818 Part of #1000 Co-authored-by: Jonah Graham <[email protected]>

Some of the changes that are about to arrive have specific impacts of API of core build. Because CBS is largely in org.eclipse.cdt.core/ui any breaking changes to the CBS API necessitate bumping the entire bundle to a new version. One of the most noticeable changes is expected to be that org.eclipse.cdt.core.build.ICBuildConfigurationProvider.createBuildConfiguration(IProject, IToolChain, String, IProgressMonitor) needs a new parameter to properly connect the target. The upcoming PR that makes the API change will document that change in the CHANGELOG-API.md and N&N documentation. Part of eclipse-cdt#1000

Adding UI into CMake Preference page that allow user to specify the location of the CMake tool and the location of CMake generators. Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-004 and IDE-82683-REQ-005

Adding UI into CMake Preference page that allow user to specify the location of the CMake tool and the location of CMake generators. Added Unit test Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-004 and IDE-82683-REQ-005

User can control the value of the CMake built type (CMAKE_BUILD_TYPE), for example Debug or Release via new UI in CMakeBuildTab Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-013

User can control the value of the CMake built type (CMAKE_BUILD_TYPE), for example Debug or Release via new UI in CMakeBuildTab Added UT for ICMakeProperties.getBuildType() Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-013

The default IBuildConfiguration is no longer used by projects that use ICBuildConfigurationProvider. For CMake, Makefile and other Core Build projects the build output folder is sometimes named "default" rather than the pattern toolName.launchMode.toolchain OS.toolchain Arch.launchTarget Id (eg: cmake.debug.win32.x86_64.Local). PR eclipse-cdt#1076 exposes new API (ICBuildConfigurationProvider.getCBuildConfigName) to encourage this naming pattern. The "sometimes" is variable and often happens when a project is first created when the active launch target is Local and the launch mode is "run", but not always. This gives a random, inconsistent impression to CDT. The Platform project always contains a IBuildConfiguration with the name IBuildConfiguration.DEFAULT_CONFIG_NAME. It seems the original Core Build system design went to some length to fit in with this and always make use of this IBuildConfiguration when pairing it with a new ICBuildConfiguration. With this PR, this no longer happens, allowing CDT code to be simplified and the build folder naming made consistent, always adhering to ICBuildConfigurationProvider.getCBuildConfigName. Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-024 Default CMake build folder

User can control the value of the CMake built type (CMAKE_BUILD_TYPE), for example Debug or Release via new UI in CMakeBuildTab Added UT for ICMakeProperties.getBuildType() Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-013

The default IBuildConfiguration is no longer used by projects that use ICBuildConfigurationProvider. For CMake, Makefile and other Core Build projects the build output folder is sometimes named "default" rather than the pattern toolName.launchMode.toolchain OS.toolchain Arch.launchTarget Id (eg: cmake.debug.win32.x86_64.Local). PR eclipse-cdt#1076 exposes new API (ICBuildConfigurationProvider.getCBuildConfigName) to encourage this naming pattern. The "sometimes" is variable and often happens when a project is first created when the active launch target is Local and the launch mode is "run", but not always. This gives a random, inconsistent impression to CDT. The Platform project always contains a IBuildConfiguration with the name IBuildConfiguration.DEFAULT_CONFIG_NAME. It seems the original Core Build system design went to some length to fit in with this and always make use of this IBuildConfiguration when pairing it with a new ICBuildConfiguration. With this PR, this no longer happens, allowing CDT code to be simplified and the build folder naming made consistent, always adhering to ICBuildConfigurationProvider.getCBuildConfigName. Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-024 Default CMake build folder

User can control the value of the CMake built type (CMAKE_BUILD_TYPE), for example Debug or Release via new UI in CMakeBuildTab Added UT for ICMakeProperties.getBuildType() Addresses Issue: CDT CMake Improvements #1000, IDE-82683-REQ-013

The default IBuildConfiguration is no longer used by projects that use ICBuildConfigurationProvider. For CMake, Makefile and other Core Build projects the build output folder is sometimes named "default" rather than the pattern toolName.launchMode.toolchain OS.toolchain Arch.launchTarget Id (eg: cmake.debug.win32.x86_64.Local). PR eclipse-cdt#1076 exposes new API (ICBuildConfigurationProvider.getCBuildConfigName) to encourage this naming pattern. The "sometimes" is variable and often happens when a project is first created when the active launch target is Local and the launch mode is "run", but not always. This gives a random, inconsistent impression to CDT. The Platform project always contains a IBuildConfiguration with the name IBuildConfiguration.DEFAULT_CONFIG_NAME. It seems the original Core Build system design went to some length to fit in with this and always make use of this IBuildConfiguration when pairing it with a new ICBuildConfiguration. With this PR, this no longer happens, allowing CDT code to be simplified and the build folder naming made consistent, always adhering to ICBuildConfigurationProvider.getCBuildConfigName. Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-024 Default CMake build folder

The default IBuildConfiguration is no longer used by projects that use ICBuildConfigurationProvider. For CMake, Makefile and other Core Build projects the build output folder is sometimes named "default" rather than the pattern toolName.launchMode.toolchain OS.toolchain Arch.launchTarget Id (eg: cmake.debug.win32.x86_64.Local). PR #1076 exposes new API (ICBuildConfigurationProvider.getCBuildConfigName) to encourage this naming pattern. The "sometimes" is variable and often happens when a project is first created when the active launch target is Local and the launch mode is "run", but not always. This gives a random, inconsistent impression to CDT. The Platform project always contains a IBuildConfiguration with the name IBuildConfiguration.DEFAULT_CONFIG_NAME. It seems the original Core Build system design went to some length to fit in with this and always make use of this IBuildConfiguration when pairing it with a new ICBuildConfiguration. With this PR, this no longer happens, allowing CDT code to be simplified and the build folder naming made consistent, always adhering to ICBuildConfigurationProvider.getCBuildConfigName. Addresses Issue: CDT CMake Improvements #1000, IDE-82683-REQ-024 Default CMake build folder

path is relative Under certain conditions*, the compiler param in the command field of the compile_commands.json is a relative path rather than absolute. When this happens, the built-ins detection was not successful and the following exception was thrown: !ENTRY org.eclipse.cdt.core 4 0 2025-02-23 20:32:10.752 !MESSAGE Error: Cannot run program "gcc": Launching failed !STACK 0 java.io.IOException: Cannot run program "gcc": Launching failed at org.eclipse.cdt.utils.spawner.Spawner.exec(Spawner.java:450) at org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:147) at org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:134) at org.eclipse.cdt.utils.spawner.ProcessFactory$Builder.start(ProcessFactory.java:273) at org.eclipse.cdt.utils.spawner.ProcessFactory.exec(ProcessFactory.java:366) at org.eclipse.cdt.core.CommandLauncher.execute(CommandLauncher.java:189) at org.eclipse.cdt.jsoncdb.core.internal.builtins.CompilerBuiltinsDetector.detectBuiltins(CompilerBuiltinsDetector.java:111) at org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.detectBuiltins(CompileCommandsJsonParser.java:290) at org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.processJsonFile(CompileCommandsJsonParser.java:193) at org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.parse(CompileCommandsJsonParser.java:455) at org.eclipse.cdt.cmake.core.CMakeBuildConfiguration.processCompileCommandsFile(CMakeBuildConfiguration.java:361) at org.eclipse.cdt.cmake.core.CMakeBuildConfiguration.build(CMakeBuildConfiguration.java:241) This meant that source file includes were not indexed and could not be opened using Open Declaration (F3) and info markers of the following type appeared in the Problems view: gcc -E -P -dM -Wp,-v "...extCmakegcc\\build\\cmake.run.win32.x86_64.Local\\detect_compiler_builtins.c" Cannot run program "gcc": Launching failed Error: Program "gcc" not found in PATH PATH=[...] extCmakegcc Unknown Compiler Builtins Detector Problem gcc -E -P -dM -Wp,-v "...extCmakegcc\\build\\cmake.run.win32.x86_64.Local\\detect_compiler_builtins.c" Cannot run program "gcc": Launching failed This patch fixes the environment issue for Core Build projects, by calling ICBuildConfiguration.setBuildEnvironment(Map<String, String>) as part of the built-ins detection setup, thereby supporting absolute and relative compiler paths. Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-011 Source code navigation and Built-ins detection *: CMake produces relative compiler path When the CMAKE_<LANG>_COMPILER variable (eg CMAKE_C_COMPILER) is set in the CMakeLists.txt *after* the project() or language commands, it causes a relative path to be used. For example, in the CMakeLists.txt below, gcc is set after project() command: cmake_minimum_required(VERSION 3.10) project (track2) set(CMAKE_C_COMPILER gcc) add_executable(${PROJECT_NAME} track2.c) The above script creates a relative compiler path in compile_commands.json: "command": "gcc -O3 -DNDEBUG -o ... Normally the CMAKE_C_COMPILER variable should be set before the project() comannd. "command": "C:\\msys64\\mingw64\\bin\\c++.exe -IC...

Under certain conditions*, the compiler param in the command field of the compile_commands.json is a relative path rather than absolute. When this happens, the built-ins detection was not successful and the following exception was thrown: !ENTRY org.eclipse.cdt.core 4 0 2025-02-23 20:32:10.752 !MESSAGE Error: Cannot run program "gcc": Launching failed !STACK 0 java.io.IOException: Cannot run program "gcc": Launching failed at org.eclipse.cdt.utils.spawner.Spawner.exec(Spawner.java:450) at org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:147) at org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:134) at org.eclipse.cdt.utils.spawner.ProcessFactory$Builder.start(ProcessFactory.java:273) at org.eclipse.cdt.utils.spawner.ProcessFactory.exec(ProcessFactory.java:366) at org.eclipse.cdt.core.CommandLauncher.execute(CommandLauncher.java:189) at org.eclipse.cdt.jsoncdb.core.internal.builtins.CompilerBuiltinsDetector.detectBuiltins(CompilerBuiltinsDetector.java:111) at org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.detectBuiltins(CompileCommandsJsonParser.java:290) at org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.processJsonFile(CompileCommandsJsonParser.java:193) at org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.parse(CompileCommandsJsonParser.java:455) at org.eclipse.cdt.cmake.core.CMakeBuildConfiguration.processCompileCommandsFile(CMakeBuildConfiguration.java:361) at org.eclipse.cdt.cmake.core.CMakeBuildConfiguration.build(CMakeBuildConfiguration.java:241) This meant that source file includes were not indexed and could not be opened using Open Declaration (F3) and info markers of the following type appeared in the Problems view: gcc -E -P -dM -Wp,-v "...extCmakegcc\\build\\cmake.run.win32.x86_64.Local\\detect_compiler_builtins.c" Cannot run program "gcc": Launching failed Error: Program "gcc" not found in PATH PATH=[...] extCmakegcc Unknown Compiler Builtins Detector Problem gcc -E -P -dM -Wp,-v "...extCmakegcc\\build\\cmake.run.win32.x86_64.Local\\detect_compiler_builtins.c" Cannot run program "gcc": Launching failed This patch fixes the environment issue for Core Build projects, by calling ICBuildConfiguration.setBuildEnvironment(Map<String, String>) as part of the built-ins detection setup, thereby supporting absolute and relative compiler paths. Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-011 Source code navigation and Built-ins detection *: CMake produces relative compiler path When the CMAKE_<LANG>_COMPILER variable (eg CMAKE_C_COMPILER) is set in the CMakeLists.txt *after* the project() or language commands, it causes a relative path to be used. For example, in the CMakeLists.txt below, gcc is set after project() command: cmake_minimum_required(VERSION 3.10) project (track2) set(CMAKE_C_COMPILER gcc) add_executable(${PROJECT_NAME} track2.c) The above script creates a relative compiler path in compile_commands.json: "command": "gcc -O3 -DNDEBUG -o ... Normally the CMAKE_C_COMPILER variable should be set before the project() comannd. "command": "C:\\msys64\\mingw64\\bin\\c++.exe -IC... Co-authored-by: Jonah Graham <[email protected]>

…1095) Under certain conditions*, the compiler param in the command field of the compile_commands.json is a relative path rather than absolute. When this happens, the built-ins detection was not successful and the following exception was thrown: !ENTRY org.eclipse.cdt.core 4 0 2025-02-23 20:32:10.752 !MESSAGE Error: Cannot run program "gcc": Launching failed !STACK 0 java.io.IOException: Cannot run program "gcc": Launching failed at org.eclipse.cdt.utils.spawner.Spawner.exec(Spawner.java:450) at org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:147) at org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:134) at org.eclipse.cdt.utils.spawner.ProcessFactory$Builder.start(ProcessFactory.java:273) at org.eclipse.cdt.utils.spawner.ProcessFactory.exec(ProcessFactory.java:366) at org.eclipse.cdt.core.CommandLauncher.execute(CommandLauncher.java:189) at org.eclipse.cdt.jsoncdb.core.internal.builtins.CompilerBuiltinsDetector.detectBuiltins(CompilerBuiltinsDetector.java:111) at org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.detectBuiltins(CompileCommandsJsonParser.java:290) at org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.processJsonFile(CompileCommandsJsonParser.java:193) at org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.parse(CompileCommandsJsonParser.java:455) at org.eclipse.cdt.cmake.core.CMakeBuildConfiguration.processCompileCommandsFile(CMakeBuildConfiguration.java:361) at org.eclipse.cdt.cmake.core.CMakeBuildConfiguration.build(CMakeBuildConfiguration.java:241) This meant that source file includes were not indexed and could not be opened using Open Declaration (F3) and info markers of the following type appeared in the Problems view: gcc -E -P -dM -Wp,-v "...extCmakegcc\\build\\cmake.run.win32.x86_64.Local\\detect_compiler_builtins.c" Cannot run program "gcc": Launching failed Error: Program "gcc" not found in PATH PATH=[...] extCmakegcc Unknown Compiler Builtins Detector Problem gcc -E -P -dM -Wp,-v "...extCmakegcc\\build\\cmake.run.win32.x86_64.Local\\detect_compiler_builtins.c" Cannot run program "gcc": Launching failed This patch fixes the environment issue for Core Build projects, by calling ICBuildConfiguration.setBuildEnvironment(Map<String, String>) as part of the built-ins detection setup, thereby supporting absolute and relative compiler paths. Addresses Issue: CDT CMake Improvements #1000, IDE-82683-REQ-011 Source code navigation and Built-ins detection *: CMake produces relative compiler path When the CMAKE_<LANG>_COMPILER variable (eg CMAKE_C_COMPILER) is set in the CMakeLists.txt *after* the project() or language commands, it causes a relative path to be used. For example, in the CMakeLists.txt below, gcc is set after project() command: cmake_minimum_required(VERSION 3.10) project (track2) set(CMAKE_C_COMPILER gcc) add_executable(${PROJECT_NAME} track2.c) The above script creates a relative compiler path in compile_commands.json: "command": "gcc -O3 -DNDEBUG -o ... Normally the CMAKE_C_COMPILER variable should be set before the project() comannd. "command": "C:\\msys64\\mingw64\\bin\\c++.exe -IC... Co-authored-by: Jonah Graham <[email protected]>

betamaxbandit · 2025-02-26T14:40:09Z

In summary, the following pull requests were completed as part of this activity (CDT CMake Improvements #1000):

Make CMakeBuildConfiguration API #1010 addresses IDE-82683-REQ-017
Improve CMake build option handling and API #1046 addresses IDE-82683-REQ-012
Provide an example of extending CMake project type in Core Build #1052 related to Improve CMake build option handling and API #1046
The active Launch Target is now saved in the ICBuildConfiguration #1076 addresses IDE-82683-REQ-016
Stops CMake build output folders being named "default" #1084 addresses IDE-82683-REQ-024
Add UI for user to control build type #1090 addresses IDE-82683-REQ-013
CMake built-ins detection successful when compile_commands.json compiler #1095 addresses IDE-82683-REQ-011

Not done:

Add UI for specifying CMake tools and generators' locations #1067 addresses IDE-82683-REQ-004 & IDE-82683-REQ-005. Paused because specification needs more work.

jonahgraham · 2025-02-26T14:44:30Z

Thanks you @betamaxbandit and @DangMinhTam382 for all your hard work on improving CMake support for CDT 12.

Updated "Release Notes and New & Noteworthy page" page with details of the Core Build improvements as part of eclipse-cdt#1000

Adding UI into CMake Preference page that allow user to specify the location of the CMake tool and the location of CMake generators. Added Unit test Addresses Issue: CDT CMake Improvements eclipse-cdt#1000, IDE-82683-REQ-004 and IDE-82683-REQ-005

Updated "Release Notes and New & Noteworthy page" page with details of the Core Build improvements as part of #1000

betamaxbandit mentioned this issue Jan 15, 2025

Make CMakeBuildConfiguration API #1010

Merged

betamaxbandit mentioned this issue Jan 17, 2025

Improve CMake build option handling and API #1046

Merged

jonahgraham mentioned this issue Jan 22, 2025

Provide an example of extending CMake project type in Core Build #1052

Merged

jonahgraham mentioned this issue Jan 29, 2025

Bump org.eclipse.cdt.core/ui bundle version to 9.0.0 #1063

Merged

DangMinhTam382 mentioned this issue Jan 29, 2025

Add UI for specifying CMake tools and generators' locations #1067

Draft

DangMinhTam382 mentioned this issue Feb 17, 2025

Add UI for user to control build type #1090

Merged

betamaxbandit mentioned this issue Feb 23, 2025

CMake built-ins detection successful when compile_commands.json compiler #1095

Merged

betamaxbandit closed this as completed Feb 26, 2025

betamaxbandit added a commit to betamaxbandit/cdt that referenced this issue Mar 1, 2025

Update Release Notes with Core Build improvements

9694cd0

Updated "Release Notes and New & Noteworthy page" page with details of the Core Build improvements as part of eclipse-cdt#1000

betamaxbandit mentioned this issue Mar 1, 2025

Update Release Notes with Core Build improvements #1100

Merged

jonahgraham pushed a commit that referenced this issue Mar 7, 2025

Update Release Notes with Core Build improvements (#1100)

d1287b0

Updated "Release Notes and New & Noteworthy page" page with details of the Core Build improvements as part of #1000

jonahgraham added this to the 12.0.0 milestone Mar 7, 2025

jonahgraham added the noteworthy Pull requests and fixed issues that should be highlighted to users label Mar 7, 2025

jonahgraham mentioned this issue Mar 8, 2025

Eclipse CDT + CMake: Eclipse index unable to resolve header files #750

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CDT CMake Improvements #1000

CDT CMake Improvements #1000

betamaxbandit commented Jan 14, 2025 •

edited

Loading

betamaxbandit commented Feb 26, 2025

jonahgraham commented Feb 26, 2025

CDT CMake Improvements #1000

CDT CMake Improvements #1000

Comments

betamaxbandit commented Jan 14, 2025 • edited Loading

betamaxbandit commented Feb 26, 2025

jonahgraham commented Feb 26, 2025

betamaxbandit commented Jan 14, 2025 •

edited

Loading