You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
org.eclipse.cdt.cmake.core.internal.CMakeBuildConfiguration currently uses a mixture of APIs to store settings relevant to the CMake build. These are:
ICBuildConfiguration.setProperty/getProperty
CMakeBuildConfiguration.getPropertiesController()
Having 2 settings APIs in use is confusing and inefficient.
org.eclipse.cdt.core.build.CBuildConfiguration.getSettings()
protected Preferences getSettings()
This is used to implement the *property API in ICBuildConfiguration, eg:
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)
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.
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
The text was updated successfully, but these errors were encountered:
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:
ICBuildConfiguration.setProperty/getProperty
CMakeBuildConfiguration.getPropertiesController()
Having 2 settings APIs in use is confusing and inefficient.
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)
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)
The text was updated successfully, but these errors were encountered: