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
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
User can control the value of the CMake built type (CMAKE_BUILD_TYPE),
for example Debug or Release via new UI in CMakeBuildTab
Added UT for ICMakeProperties.getBuildType()
Addresses Issue: CDT CMake Improvements #1000, IDE-82683-REQ-013
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
* Put Core Build and Managed Build items in separate topics.
* Added two images to Creating a CMake project.
* Added new pages about creating a CBS Makefile project, using
existing code, launch bar, building, running, and debbuggin
a project.
* Renamed "Creating a simple application" to "Creating a Managed Build
System Makefile project" and replaced two images.
* Removed "Creating a Makefile project", because it was duplicate
information.
Fixes#992
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
That is if any CPP application is under debug. Because Pin View is never
enabled other than CPP application debug session.
This also includes Action to Command migration.
Fixes https://github.com/eclipse-cdt/cdt/issues/1048
Summary:
- Add some new API to make it easier for ISVs to provide defaults.
- Fully connect UI elements to CMake build process
- Add some missing UI elements (such as customizing generator)
- CMake generator default within CDT changed to Ninja
Details:
Add API to set CMake generator default (eg Ninja) ISV can set
their desired CMake generator by overriding
`CMakeBuildConfiguration.getDefaultProperties`. ISVs can also further
fine tune the build process by overriding
`CMakeBuildConfiguration.getDefaultProperties`
Remove API `IOsOverrides` and related code. `IOsOverrides` was a partial
implementation to achieve builds in Docker containers, however the
work was not complete and it the extra code was complicating some
basic use cases of setting defaults
Add support for all generators to CMake build settings UI page by
using a Combo instead of radio buttons. The non-deprecated generators
that are built-in to CDT populate the Combo, but additional generators
can be manually entered in the Combo.
Rename clean command to clean target to better reflect its use as
the argument passed to cmake's --target command line.
Add all target for the argument passed to cmake's --target
command line when doing a normal build.
Clarify usage of UI overrides and change the UI to be "use defaults"
(i.e. invert the checkbox). This is a **breaking** change as it means
user projects that were using UI overrides will revert to using defaults.
This is done on purpose as so many little things have changed in CMake
settings, that reverting to defaults on upgrade seems like a logical
decision. In addition *use defaults* matches the other GUIs in Eclipse,
for example the MBS build command settings.
Populate all defaults in getDefaultProperties() so that all CMake build
settings are displayed as used (greyed out) and can be used as a starting
point when editing settings.
Simplify some of the code in CMakeBuildTab.
Fix parsing of extra args so that quoted strings work.
Refactored manual tests document and brought it up to date.
Correct command line option for CMake's --warn-unused-vars
Correct command line option for CMake's --warn-uninitialized
Overall this is an API breaking change and the CHANGELOG-API.md has been
updated with all the API changes in and around ICMakeProperties,
including fixing typos in WarnUninitialized methods.
Fixes#1055Fixes#818
Part of #1000
Co-authored-by: Jonah Graham <jonah@kichwacoders.com>
This will try to rerun failed tests up to three times.
The side effect is that a very broken test run will take much
longer to complete, but it is hoped for those few
https://github.com/eclipse-cdt/cdt/labels/flakytests in the system
this will resolve the issue.
Note this is applied only to the GitHub actions run, not to Jenkins
run where we build releases from. Ideally we don't want to do that
there.
In a future commit we can consider removing flakyTest from -DexcludedGroups
too.
See [surefire docs](https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html)
for details.
On GitHub I see fails in resume[gdb] (org.eclipse.cdt.tests.dsf.gdb.tests.MIRunControlTest)
with this output:
```
Terminate failed
org.eclipse.debug.core.DebugException: Terminate failed
at org.eclipse.debug.core.Launch.terminate(Launch.java:300)
at org.eclipse.cdt.dsf.gdb.launching.GdbLaunch.terminate(GdbLaunch.java:313)
at org.eclipse.cdt.tests.dsf.gdb.framework.BaseTestCase.doAfterTest(BaseTestCase.java:662)
at org.eclipse.cdt.tests.dsf.gdb.tests.MIRunControlTest.doAfterTest(MIRunControlTest.java:133)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.lang.Thread.run(Thread.java:1583)
Contains: Terminate failed
Contains: Terminate failed
790,475 "resume[gdb]" requesting gdb. Launched gdb 15.0.50.20240403.
```
which is insufficient to diagnose what is happening.
Part of #816
"script" field of a breakpoint used to be output as a tuple (<= GDB 12),
though it is a list. There are cases of flags that can be applied to
get old or new behaviour too.
This code handles both cases transparently.
See https://sourceware.org/bugzilla/show_bug.cgi?id=24285
Part of #816
This test sometimes hangs when run a lot. As best as I can tell this
is a Ubuntu problem, rather than a gdb problem as it only fails on
Ubuntu 24.04, but I am not sure. I cannot reproduce the problem
when using the UI.
Part of #816
From GDB news:
print
Printing of floating-point values with base-modifying formats like
/x has been changed to display the underlying bytes of the value in
the desired base. This was GDB's documented behavior, but was never
implemented correctly.
This commit updates the tests to accomodate GDB's change.
Fixes#210
Without the return, this code would core dump, depending
on compiler version. The compiler was generating a warning
too about the missing return.
Part of #816
The tests were relying on specific number of executable lines
in a function. However on some gdb/gcc combinations stopping
at a function stops at the line with the `{` and some
on the first line witin that function. Much of the tests
here assumed that latter. By using line tags we don't need
to worry about exact number of executable lines between entry
and area of interest. And by placing first line of code on
the same line as the opening `{` of the function, we can
have consistent stop locations when stepping into a function.
Part of #816
The combination of gcc 9.4 and gdb 9.2 in Ubuntu 20.04 have a few
minor test issues that seem to be bugs in gdb that have been since
fixed.
Part of #816
In issue #1000 a lot of the work is on exposing a better API to ISVs.
This new project serves these purposes:
- Ensure the exposed API works in practice
- Example for ISVs to use if they want to extend CMake
- Provide an in-tree example of the API in use, so future editors of
CDT have better chance of understanding *why* items are done as
they are.
PR #1010 added the ability to extend CMakeBuildConfiguration and
CMakeBuildConfigurationProvider by making the classes public
API, they used to be internal API.
This change makes it easier to reuse the code in the provider
and configuration by allowing extenders to provide their own
implementations of CMakeBuildConfiguration. This has been
achieved by adding createCMakeBuildConfiguration methods to
control which CMakeBuildConfiguration is constructed.
Follow up to #1010
In #974 I removed activities we were not using anymore, but it turns
out if LaunchUtils.enableActivity is called on a removed id, strange
things happen, such as other activities incorrectly being enabled.
This may be a bug in platform, or just undefined behavior. But because
extenders do have calls to LaunchUtils.enableActivity in their code,
leave the empty activity ids behind.
Fixes#1044
