Until we are ready for GDB 12 in the testsuite, run the GHA
checks against GDB 10 by chaning base OS to Ubuntu 20.04
instead of latest (which recently changed to 22.04)
Worksaround #210
This is the last part of finishing up 11.0.0 release, the Platform
I-Builds will be deleted soon so we point to the same versions
of those dependencies in their permanent locations.
Part of #77
Without setting dependent plug-ins to minimum version to match the
target platform we are aiming for we can imply (and therefore let install)
CDT into older versions of Eclipse where CDT does not actually work.
This can be exposed in very odd ways, such as IllegalAccessError, when
platform has allowed API changes.
However, rather than update every single bundle in CDT, only the
o.e.cdt.core/ui bundles are being updated as this should achieve the
desired result without every other bundle needing to be touched.
See Bug 536448
Part of #77
target-async is the old name for mi-async. mi-async came
into existence in GDB 7.8, but in later releases it becomes
a warning to use the old name.
Because we already have the version infra for 7.12 we
change to using mi-async from 7.12
A similar change was made for
[cdt-gdb-adapter a while ago](https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/blob/main/src/GDBBackend.ts#L114-L116)
Fixes#176
Because of
[changes](https://www.eclipse.org/eclipse/news/4.26/platform_isv.php#JobManager_Implementation)
in Eclipse Platform where the jobmanager's behaviour changes (within
the API), the consumers of the jobmanager can deadlock due to incorrect
assumptions.
In particular, where we call job.schedule(), the callback can happen
in different threads to the IJobChangeListener's. As CDT was holding
a lock while calling schedule that is also required in those
listeners, we need to no longer lock when calling schedule.
As the code already dealt with the case of when there was a delay
between the job.schedule() and where & when it was run, we can
move the schedule call out of the synchronized block.
Fixes#81
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.
Removed ICBuildConfiguration.getBinaryParserId() and
IToolChain.getBinaryParserId(). Replaced with methods that return a list
of IDs.
Updated API changes doc.
Rearranged tests so that the test for IToolChain is in a new gcc test
plugin.
Update since tags to 8.0.
Remove api filter.
Fix other since tags after removing of api filter.
Remove interface defaults.
Add default implementations where necessary.
Update tests - TBC.
Added ability to return a list of binary parser IDs, rather than a
single ID. This supports build configurations that have multiple
binaries with for example cross toolchains.
Change-Id: I1b7e47bf6a86bbd9f1c6b9646d008bac9479417d
This change solves the indexing of C/C++ files when multiple
toolchains are used in a single Makefile. This is for the use case in
which one (Linux) gcc compiler plus one or more custom embedded C
compilers (all producing ELF format binaries) are used.
To get proper indexing we need to know for each resource which
toolchain was used. The sub build configuration (via extension point
org.eclipse.cdt.core.buildConfigProvider) extends
StandardBuildConfiguration.java, and overrides method IToolChain
(List<String> commandgetToolChain). tcMap is filled with a map of
toolchains per resource. The primary toolchain keeps pointing to the
gcc toolchain.
