Improve CMake project behaviours for feature parity with Makefile projects

[jld01]

There are a number of CDT behaviours available within classic Makefile projects that are not available within CMake projects:

• Presentation of the Includes virtual resource containing include file paths within the Project Explorer
• Ability to define Build Variables and Environment which may be used to customize the behaviour of build tools
• Ability to select Container Settings (Support building in container for Cmake projects #565), Binary Parsers (for launch of objdump) and Error Parsers (Option to set Error Parsers in Core Build projects' project properties. #753) of relevance to the toolchain

This issue has been created for discussion on how we can work towards feature parity of CMake projects with classic Makefile projects.

[ewaterlander]

I would say: make Core Build (CMake and Makefile) on par with Managed Build (classic Makefile).

[ewaterlander]

A fundamental difference between Managed and Core build project is that Managed projects have a "C/C++ Build" section in the project properties and Core Build projects don't. Core build projects have the build settings in the launch configuration, and these settings are limited to selecting a toolchain and setting a build command. There is one launch configuration for Running and one for Debug, but this is hidden for the user. They are selected based on the Launch Mode in the LaunchBar. The Core Build launch configurations are not visible in the Run- and Debug Configurations windows, but only in the LaunchBar.

To get on par with Managed build the Core Build projects could also get a C/C++ Build section in the project properties, but without the Makefile generation stuff (Settings >Tool Settings).
Or the Core build launch configurations could be extended w.r.t. build settings. But I find a launch configuration a strange place to store build settings. I don't know why this was chosen in the past. Perhaps to make it simpler for the user.

Also w.r.t. launching the Core Build launch configurations are much more limited than the standard C/C++ launch configurations. I typically use the Core Build launch configuration only for building, and then a normal launch configuration for running and debug.

[ewaterlander]

The idea for a new build system came from Doug Schaefer in 2010, see Bug 321443 - Build Model Enhancements. Doug started implementing in 2015 Bug 321443 - First implementation of new build model.. CMake Core Build launches were introduced in 2016
Introduce Core Build launches and Launch Bar integration.. Doug left CDT in 2019 and since then Core Build development got slowed down a lot. The intention was that Core Build would replace Managed build, but up till today Managed Makefile is still the front flow in CDT.

I'm very much in favor of improving CMake and Makefile Core Build. In my opinion Managed Build is out of date as I wrote here.

[ewaterlander]

• Ability to define Build Variables and Environment which may be used to customize the behaviour of build tools

W.r.t. environment variables, I think this should not be added. The Core Build flow was made for environments where command line is king. See here. CDT is not the master of the build information. One user uses command line, another user uses Eclipse/CDT. And you have CI regressions. The environment should be the environment in which you start Eclipse.

If you mean CFLAGS and so on with Build Variables, for those counts the same. The user enters these in CMakeList.txt or Makefile. CDT gets it from compile_commands.json (cmake) or from build output parsing (make). CDT should not hold those variables, because the command line user would miss them.

[ewaterlander]

To get on par with Managed build the Core Build projects could also get a C/C++ Build section in the project properties, but without the Makefile generation stuff (Settings >Tool Settings). Or the Core build launch configurations could be extended w.r.t. build settings. But I find a launch configuration a strange place to store build settings. I don't know why this was chosen in the past. Perhaps to make it simpler for the user.

I think the idea to store the tool chain in the launch config was taken from the Arduino build system (I have never seen it). See here. Each launch should determine its toolchain. See also here.

For other build settings, e.g. Error Parsers selection, it's OK to put them in the Project-scoped preferences per config.

[jantje]

Not that anyone cares or anyone wants this but my 2 cents
I don't know much about cmake but I doubt it would be hard to add cmake as a builder to autoBuild.

[jld01]

Hi @ewaterlander, thank you for your useful input.

W.r.t. environment variables, I think this should not be added. The Core Build flow was made for environments where command line is king. See here. CDT is not the master of the build information. One user uses command line, another user uses Eclipse/CDT. And you have CI regressions. The environment should be the environment in which you start Eclipse.

I understand this argument, but setting up the environment outside the IDE can be quite alien to some users who, nevertheless, have a legitimate need to work with CMake projects. If the user can extend the PATH to allow for location of additional project-specific tools, for example, I see this as a big usability win.

If you mean CFLAGS and so on with Build Variables, for those counts the same. The user enters these in CMakeList.txt or Makefile. CDT gets it from compile_commands.json (cmake) or from build output parsing (make). CDT should not hold those variables, because the command line user would miss them.

At present, we use a build variable (gnu_tool_prefix) to support launching of tools such as objdump. This variable is relevant only within CDT and does not affect project build. We could consider an alternative mechanism to allow lookup of the relevant GNU tool prefix for Core Build projects based on toolchain selection.

[ewaterlander]

Hi @ewaterlander, thank you for your useful input.

I understand this argument, but setting up the environment outside the IDE can be quite alien to some users who, nevertheless, have a legitimate need to work with CMake projects. If the user can extend the PATH to allow for location of additional project-specific tools, for example, I see this as a big usability win.

Hi @jld01 ,

I think the user should be educated how the new flow works. The CDT user documentation is far behind...

Like Core Build flow, vscode also uses the environment in which it was started for building. In vscode you can set environment variables only for launching, see Is there any way to set environment variables in Visual Studio Code?.

A CDT C/C++ launch configuration also has an option to set environment variables, e.g. for debugging. The default Core Build launch configuration does not have it. For now you have to create a C/C++ launch configuration by hand if you want to do something extra. This is not so difficult. W.r.t. launching we are lacking behind with the Core Build projects. That is where we should get in parity.

At present, we use a build variable (gnu_tool_prefix) to support launching of tools such as objdump. This variable is relevant only within CDT and does not affect project build. We could consider an alternative mechanism to allow lookup of the relevant GNU tool prefix for Core Build projects based on toolchain selection.

The Core Build configuration is aware of the selected toolchain. Based on that it should be able to find all tools in the toolchain like objdump.

[ewaterlander]

Like Core Build flow, vscode also uses the environment in which it was started for building. In vscode you can set environment variables only for launching, see Is there any way to set environment variables in Visual Studio Code?.

Just checked. The vscode CMake plugin preferences does have an option to set environment variables to be passed to cmake during build.
In CDT CMake this can be done by adding additional CMake arguments in the launch configuration. I think this is the correct place, because the Core Build idea is to "build for launch". Perhaps there is some improvement needed here wrt user friendliness

[ghentschke]

@ewaterlander is the above shown screenshot part of basic cdt? I cannot fin this page

[ewaterlander]

@ewaterlander is the above shown screenshot part of basic cdt? I cannot fin this page

@ghentschke
Yes, this is standard CDT. Click on the gear in the launch bar to see the properties on the launch configuration. The Core Build launch configurations are not visible in the configurations window you get via the menu Run >> Run/Debug Configurations...
Core Build launch configurations (CMake/Makefile/Autotools/Arduino) are only visible in the launch bar.

The thing is that using vanilla CDT the standard Core Build projects are not usable for the default Local target. You can't even set for instance arguments or the working directory in the default launch configuration. The tabs are missing. How can this have happened unnoticed? I think because all the small users at home, who simple want to build a local Linux or Windows application, ran away to vscode. The semiconductor companies who build custom IDE's on top of CDT don't see the problem, because they have their own custom solution.

[ewaterlander]

Uploaded PR #821 to fix the issue of not being able to set arguments.
Also needed: Environment variables and debug settings.

[ewaterlander]

The Core Build tabs for local launch configuration are now at the level MBS local launch configurations. See #970