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
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
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
- 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.
ToggleInstructionStepModeCommand.
All the contributions of the the action has been replaced
ToggleInstructionStepModeCommand.
Enabled when introduced. Which enabled the command only when C/CPP
application is under debug in Debug View.
see https://github.com/eclipse-cdt/cdt/issues/865
The maintenance of having a streamlined standalone debugger that
starts as fast as possible is no longer possible. See for
example #591 - therefore when using standalone debugger, use
the same sets of plug-ins/features as the product it is installed
in uses. The side effect is that the standalone debugger in this
use case will start slower and extra "stuff" will be present in
this UI.
For people just building the standalone debugger, provide a minimum
feature set. This will be many more bundles than before, but
should still provide a reasonably small set that starts well.
This simplification also includes removing the the duplicates set
of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These
provided a simplified version of CDT's documentation targetted
at just standalone debugger. However there are a few problems related
to this duplication:
- The two sets of docs were not kept in sync
- The standalone docs appear in the online help, leading to
duplicated entries
- With the config.ini changes above, there is no way to exclude
the main docs in the standalone case, so remove the duplicate
A number of directly related clean-ups are included too:
- Remove the `ConfigGenerator.java` that stopped being referenced
in PR #761
- Complete the removal of `build-standalone-debugger-rcp` profile
that was started in #761. There is a small drawback to not having
this profile, the standalone debugger is very slow to build
compared to the rest of CDT. If this becomes a problem, restoring
this profile along with the changes made in #761 is reasonable.
- bring debug.product's licenses up to date
- modernize command line args to eclipse when using debug.product
Fixes#781
* Switch CI to Java 21
* Remove config generation for debug application
* Remove `org.eclipse.osgi.services` from `proxy.server` product
* Remove `org.eclipse.osgi.services` from
`org.eclipse.cdt.debug.application.product` product
* Move `org.eclipse.cdt.debug.application.product` from profile to
general part
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
* 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)
Because javax.activation 1.2.2.v20221203-1659 is in SimRel (for now)
it gets picked by p2 over jakarta.activation-api 1.2.2 which provides
the same packages.
As and when we update to Jave EE 9 (IIUC) we should be able to solve this
in a cleaner way and not rely on the old orbit bundles. Also, if and
when all projects contributing to simrel remove 1.2.2.v20221203-1659 then
we can change too.
The other option is to try to force the jakarta.activation-api 1.2.2 into
simrel and the EPP packages, but if we accidentally end up with both in
a product then other things don't work, e.g. like this error:
<details>
<summary>frame work error details</summary>
```java
!ENTRY org.eclipse.cdt.debug.application 4 0 2023-11-20 15:06:47.456
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.cdt.debug.application [101]
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf; bundle-version="2.4.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
org.eclipse.cdt.dsf [116]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.ui; bundle-version="2.4.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.ui; bundle-version="2.7.200.202311031553"; singleton:="true"
org.eclipse.cdt.dsf.ui [119]
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf; bundle-version="2.0.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb; bundle-version="7.0.0"
-> Bundle-SymbolicName: org.eclipse.cdt.gdb; bundle-version="7.2.100.202303140100"; singleton:="true"
org.eclipse.cdt.gdb [121]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb.ui; bundle-version="2.4.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb.ui; bundle-version="2.8.300.202309151124"; singleton:="true"
org.eclipse.cdt.dsf.gdb.ui [118]
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.ui
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.ui; bundle-version="2.7.200.202311031553"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb; bundle-version="[7.0.0,8.0.0)"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb; bundle-version="7.1.200.202309151124"; singleton:="true"
org.eclipse.cdt.dsf.gdb [117]
Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf
-> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.native.serial; bundle-version="1.1.100"
-> Bundle-SymbolicName: org.eclipse.cdt.native.serial; bundle-version="11.4.0.202311201859"
org.eclipse.cdt.native.serial [141]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb; bundle-version="7.0.0"
-> Bundle-SymbolicName: org.eclipse.cdt.gdb; bundle-version="7.2.100.202303140100"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.native.serial; bundle-version="1.1.100"
-> Bundle-SymbolicName: org.eclipse.cdt.native.serial; bundle-version="11.4.0.202311201859"
Unresolved requirement: Require-Bundle: org.eclipse.tm.terminal.control; bundle-version="4.0.0"
-> Bundle-SymbolicName: org.eclipse.tm.terminal.control; bundle-version="5.5.100.202311142253"; singleton:="true"
org.eclipse.tm.terminal.control [506]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf
-> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
Unresolved requirement: Require-Bundle: jakarta.activation-api; bundle-version="[1.2.2,2.0.0)"
-> Bundle-SymbolicName: jakarta.activation-api; bundle-version="1.2.2"
jakarta.activation-api [30]
No resolution report for the bundle. Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb; bundle-version="4.2.0"
-> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb; bundle-version="7.1.200.202309151124"; singleton:="true"
Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb.ui; bundle-version="7.0.0"
-> Bundle-SymbolicName: org.eclipse.cdt.gdb.ui; bundle-version="7.2.0.202211062329"; singleton:="true"
org.eclipse.cdt.gdb.ui [122]
No resolution report for the bundle. Bundle was not resolved because of a uses constraint violation.
org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"] because it is exposed to package 'javax.activation' from resources jakarta.activation-api [osgi.identity; osgi.identity="jakarta.activation-api"; type="osgi.bundle"; version:Version="1.2.2"] and javax.activation [osgi.identity; osgi.identity="javax.activation"; type="osgi.bundle"; version:Version="1.2.2.v20221203-1659"] via two dependency chains.
Chain 1:
org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"]
require: (&(osgi.wiring.bundle=jakarta.activation-api)(&(bundle-version>=1.2.2)(!(bundle-version>=2.0.0))))
|
provide: osgi.wiring.bundle: jakarta.activation-api
jakarta.activation-api [osgi.identity; osgi.identity="jakarta.activation-api"; type="osgi.bundle"; version:Version="1.2.2"]
Chain 2:
org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"]
require: (&(osgi.wiring.bundle=jakarta.xml.bind-api)(&(bundle-version>=2.3.3)(!(bundle-version>=3.0.0))))
|
provide: osgi.wiring.bundle; bundle-version:Version="2.3.3"; osgi.wiring.bundle="jakarta.xml.bind-api"
jakarta.xml.bind-api [osgi.identity; osgi.identity="jakarta.xml.bind-api"; type="osgi.bundle"; version:Version="2.3.3"]
import: (osgi.wiring.package=javax.activation)
|
export: osgi.wiring.package: javax.activation
javax.activation [osgi.identity; osgi.identity="javax.activation"; type="osgi.bundle"; version:Version="1.2.2.v20221203-1659"]
at org.eclipse.osgi.container.Module.start(Module.java:463)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1852)
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1845)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1786)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1750)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1672)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)
```
</details>
The underlying problem here is that the debug application's "product" that
gets converted to a config.ini at CDT build time doesn't expose its
dependencies fully to p2, so we end up with a built product in EPP that
doesn't have everything listed in config.ini.
There is significant maintenance overhead and it is growing to keeping
standalone as it is now working. Other options should probably be considered,
such as using the config of the full product when launching.
Fixes#591
Includes updating to latest target platform. This should
also fix#591 but it is hard to tell until after it is
integrated into SimRel and the output checked in EPP.
Fixes https://github.com/eclipse-cdt/cdt/issues/591
Part of #548
Until https://github.com/eclipse-cdt/cdt/pull/495 can be resolved
fully, apply some of the required changes.
- wildwebdeveloper was out of date, however we don't really
need wwd in CDT, but some of our dependencies have requirements
that are fufilled (e.g. linuxtools)
- duplicate entry for hamcrest 2.2 removed (other entry was just
above it!)
This includes updating to 3rd party dependencies coming from Maven
so that everything resolves properly. In particular spifly
required asm, and by doing `includeDependencyDepth="direct"` that
dependency is included in the target platform.
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
Wrong active build configuration for Core Build projects.
The CoreBuildLaunchBar tracker always made a non default build
configuration the active build configuration. In other words, it
always made the debug build configuration active.
This caused wrong build flags if a non core build launch configuration
was used to launch a core build project binary.
Fixed the CoreBuildLaunchBar tracker to set the build configuration
to active that matches the launchBar mode.
Fixes#378
This is an example of where we have somewhat an inversion of dependencies.
The existing CDT code assumes it knows about all types of editors
at compile time. In this case the LSP C Editor is a new type. However,
rather than creating a new extension mechanism here we are simply
adding the LSP C Editor to the known list as the LSP C Editor
is (or will soon be) part of CDT itself anyway (see #354)
By itself this change doesn't do anything, it needs the
change in https://github.com/Bachmann-electronic-GmbH/eclipse-cdt-lsp/pull/46/
Also-by: Gesa HENTSCHKE <Gesa.HENTSCHKE@bachmann.info>
When we update Tycho we pull in a new version of ECJ which means
we can get some differences in the class files even though
there is no difference in the source. This commit bumps
all the bundles that are affected by this.
This is kept as a separate commit from the Tycho update
because if we need to revert the Tycho update we would still
need to bump all these bundles to make jgit timestamp qualifier
happy.
Part of #320
See also #308
The previous commit in this series addresses the NPE that
can be hit. This code covers the case of the OP in #251
to actually find the correct expression to pass to GDB.
Improvement to #251
While working on #251 I had to understand what this code did,
I include the method javadoc in the hope it saves the next person
who touches this code some time.
In cases where an IASTName has no image location we were getting
NPEs in this code. See javadoc for getImageLocation for cases
when image location can be null. See #251's description for a
full case of when this can happen.
All other calls to IASTName.getImageLocation in CDT were also checked
and this was the only place in the code where the return value
was not checked for null.
Fixes#251
This change adds the ALL_FLAGS that does not limit tool options to
those declared as IOption::isForScannerDiscovery when launching the
compiler to discover compiler built-ins.
This is needed as many other flags, either entered manually in "Other
flags" or some of the existing flags with checkboxes such as "-ansi",
"-fPIC", and "-fstack-protector-all" which all affect scanner discovery
as they can all change what macros are built-in to the compiler.
The current solution has as a drawback that some settings, like -I and -D
then appear twice. For example in the "Includes" node in the "Project
Explorer"
My only reservation about this change is if there is an option
that can be specified successfully at build time, but when used
at scanner discovery time causes the compiler to fail, or return
incorrect results. Therefore I have added a new field,
excludeFromScannerDiscovery to tool options (buildDefinitions
extension point) that allows tool integrators to always exclude
a command line option from ALL_FLAGS. I have also added
a new "Other flags (excluded from discovery)" to the
"Miscellaneous" tab to allow compiler options to be entered
by the user.
