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
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>
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.
the rest of Eclipse now uses UTF-8 as default encoding.
The tm.terminal code reverts to null when the encoding
begins with "Default" and this leads to UTF-8 being
selected from Charset.defaultEncoding instead of ISO-8859
when the displayed default value is selected.
Co-authored-by: Philipp SALZGEBER <philipp.salzgeber@bachmann.info>
The CDT Debug Activites was originally added when we had two
distinct debuggers in CDT, the DSF one and the CDI one. To
eliminate confusion the preferences for the respective
debug infrastructures were only displayed if users actually
ran such a debug session.
Now with just one debug infrastructure, we should always display
the preference pages. It also removes some confusion that some
preference pages weren't visible until after you started the
debug session. So for example, users couldn't turn on or off
a bunch of default settings until after creating and launching
a debug session.
I have left the enableActivity call in GdbLaunchDelegate in
case any extenders were hiding some of their UI behind that key.
The only exception in the above is the View Performance preference
page which was misplaced in the top level Run/Debug preference
tree, even though it is CDT specific. That preference page has
been re-parented to C/C++ -> Debug
Fixes https://github.com/eclipse-cdt/cdt/issues/972
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
The Launch Bar Launch Configuration, Build Settings tab allows the user
to customise the CMake Settings (CMake generator, extra arguments, build
command and clean command). But changing these settings did not affect
the CMake build. This is now fixed.
A "Use these settings" checkbox allows the user to choose settings from
the UI or use the operating system defaults.
Includes a new system property `org.eclipse.tm.terminal.control.convertBackspace`
to allow us to disable this new behaviour in the field if it turns out that
some terminal/host combination does not like this conversion.
Fixes#392
When a more complete implementation of ANSI Escape sequence for
renaming terminal titles was added in
[CDT 10.2](https://github.com/eclipse-cdt/cdt/blob/main/NewAndNoteworthy/CDT-10.2.md#rename-terminal-tab)
it caused a regression in use cases where extenders of the terminal
wanted to retain control of the terminal's title.
This commit adds a new flag that will prevent the title of the
terminal tab from being updated from ANSI escape sequences.
Fixes#494
Looking at the logs, it seems that the regression is caused at 8bec791
where support for multi-process was added. We removed breakpoints
tracking support from final launch sequence and moved it to debug new
process and attach to process logic but none of these are run for remote
attach launch, hence breakpoint tracking is not started for remote
attach launch.
To fix the problem, IGDBProcesses.attachDebuggerToProcess(..) is updated
to handle remote attach launch as well instead of final launch sequence
handling it.
This commit is created after reverting 7bddb5f and 96839a0 which is the
older fix done to fix this issue and the other commit was to fix the
regression caused by the old fix.
The problem with older fix was that for non-stop mode, attach to process
was not working for remote launches when there is already a process
being debugged. Note that to use this feature, gdbserver should be
started with --multi option.
* Revert "Bug 580259: Not all remote session have a connected process"
This reverts commit 96839a029d.
* Revert "Bug 528145 - Attach debugger to a gdbserver remote session"
This reverts commit 7bddb5f4cb.
Removed the manually maintained table of contents, instead use
the contents feature in GitHub to navigate. The spans have
all been removed because they were not working anyway, at least
on github.
This change was inspired by PR #336 where a contributor was updating
this document and I didn't think it was a great idea to send it back
to them to add the TOC entry.
Option to override the matching of macro defines for the Core Build
GCC toolchain. This may be needed for custom compilers.
Also-by: Jonah Graham <jonah@kichwacoders.com>
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.
