![]() 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 |
||
---|---|---|
.. | ||
images | ||
OlderReleases | ||
CDT-10.0.md | ||
CDT-10.1.md | ||
CDT-10.2.md | ||
CDT-10.3.md | ||
CDT-10.4.md | ||
CDT-10.5.md | ||
CDT-10.6.md | ||
CDT-10.7.md | ||
CDT-11.0.md | ||
CDT-11.1.md | ||
CDT-11.2.md | ||
CDT-11.3.md | ||
CDT-11.4.md | ||
CDT-11.5.md | ||
CDT-11.6.md | ||
CDT-12.0.md | ||
CHANGELOG-API.md | ||
README.md |
CDT Release Notes and New & Noteworthy
What's new and noteworthy in:
- CDT 12.0/2025-03
- CDT 11.6/2024-06
- CDT 11.5/2024-03
- CDT 11.4/2023-12
- CDT 11.3/2023-09
- CDT 11.2/2023-06
- CDT 11.1/2023-03
- CDT 11.0/2022-12
- CDT 10.7/2022-06
- CDT 10.6/2022-03
- CDT 10.5/2021-12
- CDT 10.4/2021-09
- CDT 10.3/2021-06
- CDT 10.2/2021-03
- CDT 10.1/2020-12
- CDT 10.0/2020-09
CDT LSP
The CDT LSP (LSP based C/C++ Editor) provides its own changelog highlighting its release notes and new and noteworthy entries.
Older Versions
Older Versions
Older Versions
Older versions of CDT's New & Noteworthy page have not been converted from Wikitext to GitHub markdown, instead these older pages have simply been saved from the browser to preseve them. This may lead to some minor rendering issues that hopefully do not detract too much from the overall information provided.
- CDT 9.11/2020-03
- CDT 9.10/2019-12
- CDT 9.9/2019-09
- CDT 9.8/2019-06
- CDT 9.7/2019-03
- CDT 9.6/2018-12
- CDT 9.5/Photon
- CDT 9.4/Oxygen.2
- CDT 9.3/Oxygen
- CDT 9.2/Neon.2
- CDT 9.1/Neon.1
- CDT 9.0/Neon
- CDT 8.8/Mars.1
- CDT 8.7/Mars
- CDT 8.6
- CDT 8.5
- CDT 8.4/Luna
- CDT 8.3
- CDT 8.2/Kepler
- CDT 8.1/Juno
- CDT 8.0/Indigo
- CDT 7.0/Helios
- CDT 6.0/Galileo
- CDT 5.0
- CDT 4.0
API Changes
The Eclipse CDT project announces and tracks breaking API changes in CHANGELOG-API.
How to write a New & Noteworthy entry
How to write a New & Noteworthy entry
Use the model of any of the previous New & Noteworthy entry pages as a starting point. CDT 10.3/2021-06 is a fairly extensive entry and is a useful page to copy examples from.
Using Images
Upload images to the images/
subfolder and prefix the file with the version number, e.g. CDT-10.5-
.
The images should be embedded using the <img>
tag with (gernally) a width of 50%
like this:
<p align="center"><img src="images/CDT-10.0-CTAD.jpg" width="50%"></p>
Referecing Code
Especially when writing New & Noteworthy entries about API it is useful to link to the file. This should be done using a relative path, such as:
The [SerialPort](../native/org.eclipse.cdt.native.serial/src/org/eclipse/cdt/serial/SerialPort.java) supports arbitrary baud rates.
which renders like this:
The SerialPort supports arbitrary baud rates.
API Changes and Improvements
Improvements and changes to API should be announced in the New and Noteworthy for the release so they get visibility. Linking directly to the code or Javadoc for the new API is encouraged.
API Breakages and Removals
Anything that breaks or removes API should be listed in the CHANGELOG-API. If the API change is very significant (such as a new version of Java) listing it in the New and Noteworthy for the release is also advisable.