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.
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>
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
* remove invalid tycho resolver config (not valid since many versions)
* fix PMD plugin configuration (config attribute was renamed in 3.18)
* remove duplicate versions already managed in pluginManagement section
* fix indentation
* move all not yet configured versions into pluginManagement of the
parent module to avoid further duplication
* consume the target platform as file, not as maven artifact (this
simplifies building a single module A LOT)
* remove invalid tycho-source-plugin configuration
* disable tycho consumer POM generation (not needed here, and avoids a
warning in each module)
* remove prerequisites. that's for maven plugins only, and this POM
already contains the better suited similar maven enforcer rule
* enforce UTF-8 for javadoc generation (the build fails on Windows
otherwise, trying to read some Japanese? characters with the Windows
default encoding)
[#407] fix CompilerBuiltinsDetector for msys2 on Windows
The cc.exe from mingw64 (part of Msys2) on Windows needs the bin folder
to be on the PATH to be executed. e.g. 'C:\msys64\mingw64\bin' must be
part of the PATH environment variable
fixes#407
Some bundles are bumped because dev happened between 11.2 release and
this version bump. The most significant change that happened
was the bump in Tycho version which changed ECJ version and
hence some class files changed
Part of #420
* recognize source file extensions ".ccm", ".cxxm", and ".c++m"
cmake 3.27 release notes: The "CXX" language now treats source file
extensions ".ccm", ".cxxm", and ".c++m" as C++.
Signed-off-by: 15knots <11367029+15knots@users.noreply.github.com>
Warning in build.properties will be errors when they run
in the tycho build, like this:
```
Error: Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:2.7.5:package-plugin
(default-package-plugin) on project org.eclipse.cdt.core.tests:
/home/runner/work/cdt/cdt/core/org.eclipse.cdt.core.tests/build.properties:
bin.includes value(s) [test.xml] do not match any files. -> [Help 1]
```
So make them errors in the workspace so that the issue is
detected before push.
Some build.properties issues don't affect the build, but
are still indicative of a problem.
This mostly is using diamond operator, but includes
adding missing @Override and organizing imports and
applying formatting improvements in the JDT formatter.
Change-Id: Id91cbff33b0a039cc5121945ffbc407ecba45866
The CDT Cleanup profile had a bunch of extra cleanups applied to it, this
prevents running the CDT cleanup profile manually to simulate running the
save actions on all Java files
Change-Id: Iad491e1258a4ba90d81d1457ea0f6779e3663e38
All the about.html files are updated, so every bundle that hasn't
already had a bump in 10.7 needs one now
Change-Id: I6143d2fbe77a58a3a6d2f4a226d96087117f9ac1
Tycho will automatically generate the content of the pom.xml, so no
need to define it explicitly.
The maven attribute reports an error in the problem view that cannot be
fixed without manually removing the attribute. Left from an earlier
version of the plugin?
Contributed by STMicroelectronics
Change-Id: I733f2b048e8d80eca8bceee1526734b4c4dbd75b
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
