- add a new fragment 'org.eclipse.cdt.core.linux.riscv64' containing
compiled riscv64 natives suitable for the Linux riscv64
platform.
- add the 'libserial.so' binary compiled for
Linux riscv64, for the serial communication interface.
- add the linux/gtk/riscv64 environment triplet to various Maven
build scripts to support building CDT software for that environment.
Fixes#980
It is already mentioned in the requirement section and therefore
duplicated requirement. Also org.eclipse.tm.terminal.connector.local has
a require-bundle so it will be included anyways.
To fix https://bugs.eclipse.org/bugs/show_bug.cgi?id=460277 many years
ago some workarounds were added to the terminal to allow adapting
git inputs to locations to open a terminal with.
Since that workaround was added it is no longer necessary because egit
now adapts objects and provides selections in a way that means we don't
need it anymore. In particular 316d0971ad
adapts inputs to Files that we know how to open with.
Fixes https://github.com/eclipse-cdt/cdt/issues/1202
The plugin org.eclipse.tm.terminal.view.core is moved to platform and
should therefore be handled like any other third party dependency. It
actually is already part of the feature imports and the
org.eclipse.tm.terminal.view.ui require bundle it, so mentioning that
one is actually redundant and fixes it to that particular version
otherwhise.
We use CLI to read address size, replacing MI expression evaluation
which is not supported by LLDB-MI outside the context of a running
process.
We accommodate the LLDB response format when reading addressable size.
We assume little-endian since CLI 'show endian' is not supported.
C/C++ Projects view makes eclipse unresponsive if it has more than 70k
files in a directory inside a cpp project. So we can set up viewr limit
for the JFace viewer.
see https://github.com/eclipse-cdt/cdt/issues/1180
Remove unneeded dependencies in the help bundle because the
infocenter on help.eclipse.org only includes help bundles.
These removed dependencies were actually unused.
Fixes https://github.com/eclipse-cdt/cdt/issues/1170
Using:
```
mvn org.eclipse.tycho.extras:tycho-version-bump-plugin:4.0.12:update-manifest
```
and then multiple iterations to bump the bundle-version:
```
mvn verify org.eclipse.tycho:tycho-versions-plugin:4.0.12:bump-versions -Dtycho.bump-versions.increment=100 -DskipDoc=true -DskipTests=true -P baseline-compare-and-replace -fae -Djgit.dirtyWorkingTree-cdtDefault=warning
```
Make sure bounds of all dependencies match what we built against. This
prevents issues such as Bug 536448 from recurring. In 2025-06 there
are a number of Eclipse Platform changes that make CDT susceptible
to these types of issues again.
Note that this change is similar to previous iterations, such
as 1087dc5f22, but with the automatation
we can now apply this to *all* bundles.
In addition, with the tighter version constraints, building from
simrel repo for the jniheader (releng/scripts/do_rebuild_natives.sh)
is no longer sufficient. This speedup has been removed as it was probably
incorrect to have by default.
The api filters were introduced because some bundles are re-exported. Those
re-exported bundle requirements mean that technically we need to bump
the version, but in reality we effectively required the range as now
documented anyway, so doing a major version bump is unneeded.
The terminal control is migrated to the Eclipse platform, as those it
should be handled like a thrid-party dependency an not directly included
with an exact version in the feature.
This now changes it to a requirement with a lower bound of 5.5 excluding
the next major version. That way CDT and other consumers can gracefully
upgrade to the new platform variant.
The Build type combo custom value was lost when switching to another tab and back again.
Solution: Add modifyListener for buildTypeCombo and generator combo to keep properties up-to-date when switching tab.
Fixes#1118
Currently if I get passed a Process from by a method call I can check it
for the Spawner and can already call special methods like hangup(). But
there is no way to get access the the PTY used to create the Spawner so
for example one can't call PTY#setTerminalSize or query any other
properties.
This now adds a new method pty() that returns this instance for further
investigation and actions.
As we approach the release now I collapsed all the milestones into
the CDT 12.0.0 one as the milestone releases are not really public
once the release is complete.
Under certain conditions*, the compiler param in the command field of
the compile_commands.json is a relative path rather than absolute. When
this happens, the built-ins detection was not successful and the
following exception was thrown:
!ENTRY org.eclipse.cdt.core 4 0 2025-02-23 20:32:10.752
!MESSAGE Error: Cannot run program "gcc": Launching failed
!STACK 0
java.io.IOException: Cannot run program "gcc": Launching failed
at org.eclipse.cdt.utils.spawner.Spawner.exec(Spawner.java:450)
at org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:147)
at org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:134)
at org.eclipse.cdt.utils.spawner.ProcessFactory$Builder.start(ProcessFactory.java:273)
at org.eclipse.cdt.utils.spawner.ProcessFactory.exec(ProcessFactory.java:366)
at org.eclipse.cdt.core.CommandLauncher.execute(CommandLauncher.java:189)
at org.eclipse.cdt.jsoncdb.core.internal.builtins.CompilerBuiltinsDetector.detectBuiltins(CompilerBuiltinsDetector.java:111)
at org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.detectBuiltins(CompileCommandsJsonParser.java:290)
at org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.processJsonFile(CompileCommandsJsonParser.java:193)
at org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.parse(CompileCommandsJsonParser.java:455)
at org.eclipse.cdt.cmake.core.CMakeBuildConfiguration.processCompileCommandsFile(CMakeBuildConfiguration.java:361)
at org.eclipse.cdt.cmake.core.CMakeBuildConfiguration.build(CMakeBuildConfiguration.java:241)
This meant that source file includes were not indexed and could not be
opened using Open Declaration (F3) and info markers of the following
type appeared in the Problems view:
gcc -E -P -dM -Wp,-v
"...extCmakegcc\\build\\cmake.run.win32.x86_64.Local\\detect_compiler_builtins.c"
Cannot run program "gcc": Launching failed
Error: Program "gcc" not found in PATH
PATH=[...]
extCmakegcc Unknown Compiler Builtins Detector Problem
gcc -E -P -dM -Wp,-v
"...extCmakegcc\\build\\cmake.run.win32.x86_64.Local\\detect_compiler_builtins.c"
Cannot run program "gcc": Launching failed
This patch fixes the environment issue for Core Build projects, by
calling ICBuildConfiguration.setBuildEnvironment(Map<String, String>) as
part of the built-ins detection setup, thereby supporting absolute and
relative compiler paths.
Addresses Issue: CDT CMake Improvements #1000, IDE-82683-REQ-011 Source
code navigation and Built-ins detection
*: CMake produces relative compiler path
When the CMAKE_<LANG>_COMPILER variable (eg CMAKE_C_COMPILER) is set in
the CMakeLists.txt *after* the project() or language commands, it causes
a relative path to be used. For example, in the CMakeLists.txt below,
gcc is set after project() command:
cmake_minimum_required(VERSION 3.10)
project (track2)
set(CMAKE_C_COMPILER gcc)
add_executable(${PROJECT_NAME} track2.c)
The above script creates a relative compiler path in
compile_commands.json:
"command": "gcc -O3 -DNDEBUG -o ...
Normally the CMAKE_C_COMPILER variable should be set before the
project() comannd.
"command": "C:\\msys64\\mingw64\\bin\\c++.exe -IC...
Co-authored-by: Jonah Graham <jonah@kichwacoders.com>
If the CDT Variable is APPEND or PREPEND, and the incoming environment
did not contain that variable name, the resulting environment would
have null.
For example, if PATH was not set on the incoming environment, and
PATH was supposed to be prepended with /usr/bin, this method
would have set PATH=/usr/bin:null
This change ensures that the delimeter + null are not prended/appended
when the incoming value is null.
CMake compile_commands.json file is not found even though it has been
created. During a CMake build's generation stage, it generates the
compile_commands.json file inside the build folder. However,
when it comes to be used it is not found because it hasn't been
reliably refreshed.
To solve this, the file resource is refreshed
Co-authored-by: John Moule <evil_bandit_betamax@yahoo.co.uk>
Messages such as "make: Entering directory" are now processed so
that the scanner info builder knows the correct full path to use
for build.
Without this code calls to ToolChain.getResourcesFromCommand() would
pass in the wrong directory and resources could not be reliably
calculated. With the incorrect calculation the scanner info does
not get applied to the file correctly and the file cannot be indexed
reliably.
Without this the build and clean command entered in the CBS
settings could be parsed and re-assembled incorrectly.
A simple example is that an extra space (e.g. "make clean") would
lead to an error when running make like:
```
make: *** empty string invalid as file name. Stop.
```
This happened because the code used trivial split on " " and join
with " " to handle parsing that command line string into array of
arguments. This change fixes that by using the functionality already
available in CommandLineUtil
Fixes#1072
Initially CommandLineUtil.argumentsToString was used to provide properly
quoted string when interacting with GDB. But it is also useful to
print a string that can be copied + pasted to a terminal for the user.
When doing this the always quote every argument looks less nice, so
this change updates the code to only quote argument if needed.
Tests have also been added for the quoting.
Improves look and feel of changes in #1073
