Under some circumstances it can happen that a BuildConfiguration is
registered in the CBuildConfigurationManger as both a valid and
invalid ICBuildConfiguration counterpart. This results in a "Build not
configured correctly" error when trying to build a CoreBuild project.
This change removes valid build configurations from the invalid list
before looking for the counterpart.
Fixes#1193
- 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
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
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.
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.
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.
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
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
new AdaptedSourceViewer was unnecessarily upcast to ISourceViewer
leaving a bunch of null checks and instanceof checks in the rest
of the method. This commit removes the unneeded code.
This extra complication was a result of CDT following JDT, but the JDT
case has much more configurability which meant the extra instanceof
and null checks are needed for JDT case.
In addition to the active launch mode and toolchain, the active Launch
Target is now used to determine the Core Build Configuration
(ICBuildConfiguration).
The build output folder name now ends with the name of the Launch Target
(eg: cmake.debug.win32.x86_64.Local)
Additionally, API added to allow the ISV to configure the build output
folder name.
The ICBuildConfigurationProvider implementations, shown below, have been
tidied up to use common code.
CMakeBuildConfigurationProvider
AutotoolsBuildConfigurationProvider
MakefileBuildConfigurationProvider
MesonBuildConfigurationProvider
Addresses Issue: CDT CMake Improvements #1000, IDE-82683-REQ-016 Launch
Targets used in ICBuildConfiguration
Addresses Issue: CDT CMake Improvements #1000, IDE-82683-REQ-018 Build
output folder name
Some of the changes that are about to arrive have specific impacts
of API of core build. Because CBS is largely in org.eclipse.cdt.core/ui
any breaking changes to the CBS API necessitate bumping the entire
bundle to a new version.
One of the most noticeable changes is expected to be that
org.eclipse.cdt.core.build.ICBuildConfigurationProvider.createBuildConfiguration(IProject, IToolChain, String, IProgressMonitor)
needs a new parameter to properly connect the target. The upcoming
PR that makes the API change will document that change in the
CHANGELOG-API.md and N&N documentation.
Part of #1000
With some better Javadocs the cross referencing between IConsole
and the UI aspects of the console is a little easier to follow.
This resolves#1059 in two parts:
1. For Core Build System this update consistently uses info stream to
show information messages and output stream to be stdout of launched
build tool. This resolves the "Build Complete" appearing as the output
color when doing clean (See screenshots in #1059)
2. CBuildConfiguration.watchProcess(IConsole, IProgressMonitor) incorrectly
passed the info stream as the output stream. Mostly this was used for
the clean stage of builds. This resolves the CMake output like ("Cleaning
all built files...") appearing as the info color when doing clean (See
screenshots in #1059)
Fixes#1059
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
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
The documentation for GCC, and other compilers, stipulates that
__DATE__ with a day of month less than 10 should be prefixed by a space,
not a zero.
Contributed by STMicroelectronics
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
_This commit adds to #8407bd8d52c6c to apply the same fix to
another place that does the same operation on all fds._
When _SC_OPEN_MAX (max nr of open files limit per process) is a very
big number, then closing all possible file handles can take a while.
This change first tries to use the syscall close_range() if available,
falling back to use /proc/self/fd to close only open file handles,
and lastly falling back to the old way of closing all possible handles
one after another.
In general, the first or second approach should be available
which speeds up the pty spawning.
Refs JetBrains/pty4j#147
Copied from 04685d870f
(which is EPL 1.0)
Co-authored-by: Sergey Simonchik <sergey.simonchik@jetbrains.com>
When _SC_OPEN_MAX (max nr of open files limit per process) is a very
big number, then closing all possible file handles can take a while.
This change first tries to use the syscall close_range() if available,
falling back to use /proc/self/fd to close only open file handles,
and lastly falling back to the old way of closing all possible handles
one after another.
In general, the first or second approach should be available
which speeds up the pty spawning.
Refs JetBrains/pty4j#147
Copied from 04685d870f
(which is EPL 1.0)
Co-authored-by: Sergey Simonchik <sergey.simonchik@jetbrains.com>
When the project's active IBuildConfiguration has the default name and
the chosen ICBuildConfigurationProvider.getCBuildConfiguration does not
support the IBuildConfiguration.DEFAULT_CONFIG_NAME and returns null,
this can cause the project's ScannerInfoProvider to become "stuck"
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=413357) on the wrong
setting (eg LanguageSettingsScannerInfoProvider instead of
ICBuildConfiguration) until Eclipse is restarted or the project is
closed and reopened. When this happens, the indexer does not function.
This problem may arise if an ISV contributes a
ICBuildConfigurationProvider which has very specific naming conventions
for it's build configurations.
The solution uses the API (resetCachedScannerInfoProvider(project)),
introduced by 413357, to reset the project's ScannerInfoProvider when a
new ICBuildConfiguration is created.
Added support for LLVM optimization remarks to the GCC c/c++ error
parser. They were falsly treated as errors (OtherError). Now they are
treated as generic infos. GCC has no diagnostic messages of 'remark'
type. Since GCC and LLVM messages are very similar, no separate LLVM
error parser was created.
Fixes#752
