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
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.
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
For ISV integration/extension to CDT CMake, it is necessary to extend
several non-API classes (eg: CMakeBuildConfiguration,
CMakeBuildConfigurationProvider). This would cause "Discouraged access:
The type XXX is not API" warnings.
The classes have now been made API so can be extended without warnings.
Addresses Issue: CDT CMake Improvements #1000, IDE-82683-REQ-017
Extending CMakeBuildConfiguration
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
The additional CMake arguments added by the user in the launch
configuration UI are added at the end of the CMake command, such that
the user is able to override arguments set by the system.
The CMAKE_BUILD_TYPE is added to CMake configuration build, based on the
active launch mode; DEBUG_MODE sets a buildType of "Debug", everything
else sets a buildType of "Release".
Note, the CMake CMAKE_BUILD_TYPE definition is not directly equivalent
to the Launch Bar Launch Mode; there might be a scenario where the user
wants to launch a debug session using the CMake Release build and not
run it. However, for most cases this is probably sufficient.
For Issue CMake projects are ignoring the Launch mode Run/Debug #807.
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.
* 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)
Yaml 2.0 fixes CVE-2022–1471 to error on object references. This
commit adapts our use of Yaml to not output object references
anymore and on loading explicitly allow object references to
expected types.
Fixes#498
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
Includes:
- Sign all artifacts, particularly 3rd party with CDT's PGP key
- Using maven version managed and updated by EF Webmasters
- Update to latest SnakeYAML
- Move some 3rd party dependencies to Import-Package (instead of
Require-Bundle)
Snakeyml recentlyish came out with 2.0 version and more recently
TM4E started using the 2.0 version. As TM4E snapshots are in our
target platform we started failing as we started wiring to the newer
version due to a missing underbound on our dependency.
A separate task of updating to recent snakeyaml will be done as part
of #387
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.
Fixes out-of-the-box deprecation warnings, the template now specifies a
minimum CMake version of 3.10
Allows project names containing spaces by using freemarker syntax to
remove them where necessary in the CMakeLists.txt file.
Demonstrates how to implement the common idiom of configuration header
files.
Switch from the standard Java ProcessBuilder to the CDT CommandLauncher
for new style core build projects.
The CommandLauncher uses a more sophiscated mechanism for watching the
spawned process allowing us to interrupt the process when the user hits
the stop button on the launchbar by properly listening to a monitor.
The change adds new API to CBuildCongifuration that takes a progress
monitor, and changes all the affected build configuration types to use
this new API.
Change-Id: I0c4225616ad8331c2cea28bcb502028455a8ea71
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
Add API to o.e.tools.templates.ui that hooks into the smart import
feature and allows easy implementation of configurators for various
CDT project types.
Project types that have a IGenerator may use this API to offer smart
import functionality by registering their implementation using the
org.eclipse.ui.ide.projectConfigurator extension point.
This change includes project import implementations for Meson and
CMake project types.
For these project types users can use the normal project import
workflow for their existing non-Eclipse CMake projects instead of
using the New Project Wizard. As an additional benefit, users
can now also import more than one project at a time, even nested
projects.
Change also includes SWTBot tests to exercise the feature.
Signed-off-by: Mat Booth <mat.booth@gmail.com>
Change-Id: I96589e86bee561aa200a4a4487549305765d6409
