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>
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
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
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>
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
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.
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
Use IFile to specify the file to parse instead of a file-name implicitly
calculated from CBuildConfiguration.
Change-Id: If9d66a0b7533e9e403bc22fa21bf8e6e8fa80436
Signed-off-by: Martin Weber <fifteenknots505@gmail.com>
