Overhaul CMake build settings

[betamaxbandit]

Overhaul CMake build settings

org.eclipse.cdt.cmake.core.internal.CMakeBuildConfiguration currently uses a mixture of APIs to store settings relevant to the CMake build. These are:

1. ICBuildConfiguration.setProperty/getProperty

2. CMakeBuildConfiguration.getPropertiesController()

Having 2 settings APIs in use is confusing and inefficient.

1. org.eclipse.cdt.core.build.CBuildConfiguration.getSettings()
   protected Preferences getSettings()
   This is used to implement the *property API in ICBuildConfiguration, eg:

   ICBuildConfiguration.setProperty(String, String)
   ICBuildConfiguration.getProperty(String)

It uses org.osgi.service.prefs.Preferences

When a ICBuildConfiguration is created/accessed, this is central to storing the build configuration toolchain, launch mode etc.
It is also used by the UI (CMakeBuildTab) to store CMake settings like the generator and -D define arguments, which can be set using the Launch Bar Launch Configuration dialog. For example:
org.eclipse.cdt.cmake.ui.internal.CMakeBuildTab.initializeFrom(ILaunchConfiguration)

2. org.eclipse.cdt.cmake.core.internal.CMakeBuildConfiguration.getPropertiesController()
   private CMakePropertiesController getPropertiesController()
   This uses a file to store settings:
   ".settings/CDT-cmake.yaml"
   This arrangement was put in place [1], but never really utilised.
   There are a lot of CMake settings stored in org.eclipse.cdt.cmake.core.properties.ICMakeProperties which are used during a CMake build.

It would make sense to rationalise the settings arrangement and do things using one of the APIs above.
I would vote for using the Preferences approach as it is the standard approach in Eclipse.

Questions
A) Will removing the YAML file have any impact on the cmake4eclipse (https://github.com/15knots/cmake4eclipse) integration in CDT?

B) While doing this work, it would be wise to consider the impact of any future implementation of CMake file API (#419)

[1] #814 (comment)

Hi @15knots , Can you say what the purpose of the YAML file is please?
I planned to allowto persist option values for the cmake command-line on a per-projecz level in the yaml file. But when I found out that some of the cmake options are passed through totally undocumented properties from a project not being part of CDT (launchbar plugin) I gave up. You may safely delete the stuff dealing with that or find a way to combine both the YAML stettings and the launchbar settings. Martin

[15knots]

A) Will removing the YAML file have any impact on the cmake4eclipse (https://github.com/15knots/cmake4eclipse) integration in CDT?

No, it won't (from the author of cmake4eclipse)

[ewaterlander]

Hi,

I also vote for the preferences approach (option 1).