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
This was supposed to be a check to ensure adoc generation was
working, but it interferes with the overall check code cleanliness
as it leads to jgit dirty errors.
The generation of the docs is done as part of the build too, so
it is redundant to do them here.
When we decided to delay CDT 12.0 by 3 months it also meant that
the desired target was 2024-12, this commit makes this change
across the target platform
- Migrate all getting_started from html to adoc
- Document (in README.md) notes on migrating html to adoc
- Reorganize generation of adoc slightly so that
- all directories can be generates at once
- output suffix changed to htm so that migrated files
exist at the same URL on help.eclipse.org
- Add generation to the cleanliness checks to ensure that the
html matches adoc
- Manage the adoc headers with a script as that is a large section
of copy-pasted code on each adoc file (see README + adoc-headers.txt)
- Move maven version info to pluginManagement (consistency with other
maven plug-ins)
- New profile "asciidoc-auto-refresh" which will auto build the
files as edited.
Prerequisite of #992
Beta versions of maven plugins are omitted from this
upgrade.
A new version of Tycho brings in an update ECJ which means some
of the class files are different, hence the need to bump versions
of bundles too.
A new calendar year brings an update to Copyrights
The CDT Debug Activites was originally added when we had two
distinct debuggers in CDT, the DSF one and the CDI one. To
eliminate confusion the preferences for the respective
debug infrastructures were only displayed if users actually
ran such a debug session.
Now with just one debug infrastructure, we should always display
the preference pages. It also removes some confusion that some
preference pages weren't visible until after you started the
debug session. So for example, users couldn't turn on or off
a bunch of default settings until after creating and launching
a debug session.
I have left the enableActivity call in GdbLaunchDelegate in
case any extenders were hiding some of their UI behind that key.
The only exception in the above is the View Performance preference
page which was misplaced in the top level Run/Debug preference
tree, even though it is CDT specific. That preference page has
been re-parented to C/C++ -> Debug
Fixes https://github.com/eclipse-cdt/cdt/issues/972
The docker images all have new, simpler names and use Ubuntu 20.04
(instead of 18.04) as their base.
A few new tools have been added, specifically what is needed for:
- Linux on RISC-V - see #980
- Winodows on ARM - see #969Fixes#976
Refactors the initialization code of PTY to allow code to avoid
loading WinPTY if it isn't needed. The previous code would
load WinPTY even if ConPTY was in use.
To achieve this the code was refactored to have cleaner state
with a new field ptyType that replaces isConPTY, isWinPTY and
hasPTY.
This is needed so that WoA can run without needing to port the
unneeded WinPTY library. In particular, the winpty.dll and
pty.dll are no longer used on WoA.
Part of #969
- add a new fragment 'org.eclipse.cdt.core.win32.aarch64' containing
re-compiled Arm64 natives suitable for the Windows on Arm64 platform.
- add the 'serial.dll' binary re-compiled for Windows on Arm64.
- add the win32/win32/aarch64 environment triplet to various Maven
build scripts to support building CDT software for that environment.
The updated dlls/exes are not included in this commit and will be provided
in subsequent commits with the corresponding update to build infrastructure
Part of #969
Do not check for binaries in the project directory if the user defined
a binary in the Main tab. This supports the case where the user
disables auto build and selects a binary outside the project directory.
Otherwise the binaries check would stop the launch with the message
that no binaries are found in the project.
The launch configuration for local Core Build projects got the
Debugger and Source tabs in debug mode. Now the user can set the stop
at startup, a specific debugger, and all other Debug options as we
know from Managed Build projects.
The GdbLaunch class automatically picks up all the debug settings from
these new tabs. No additional code was needed for that.
The composition of Core Build tab groups is now fully done via the
launchConfigurationTabGroups extension-point.
This change relates to #758. It affects all Core Build projects,
including CMake projects.
A new Main Tab was created for Core Build local projects based on the Main
Tab used for the classic Managed Build projects. It adds these
features:
* Option to select a different binary.
* Option to control launch pre-builds.
The default value for the binary is empty string. With empty string
the behaviour for binary selection stays the same as it was.
The project name is fixed and cannot be changed. A Core Build launch
configuration is created with the project and tied to it.
There is no option to select a build configuration, because for Core
Build projects this is selected via the LaunchBar's Launch Mode.
This change relates to #758. It affects all Core Build projects,
including CMake projects.
License vetting status check / call-license-check (push) Failing after 1s
Code Cleanliness Checks / build (push) Failing after 1m16s
Build and Test / build (push) Failing after 1m19s
and Executables Views.
Similar to Memory View and Debug Console View, We can use
org.eclipse.cdt.debug.ui.debugging for Visualizer and Executables Views
see https://github.com/eclipse-cdt/cdt/issues/918
Added an Environment tab to the Core Build launch configurations for
the Local target. Similar as the standard C/C++ Application launch
configurations for Managed Build.
Added the CArgumentsTab to the Core Build launch configuration for the
Local target. This enables users to set command line arguments and
specify a working directory.
