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
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
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
Removed the 'Experimental' label in project creation wizard for Core
Build Makefile projects. Seven years after the inception it's time to
remove it. Core Build Makefile is now in a usable state. The
'Experimental' label scares users away from it, making them fall back
to the old Managed Build Makefile projects.
Includes:
- Created a new extension point to provide the opportunity to
incorporate additional information into the file
- New tests for the generator
- Preference page to enable/disable generator
Fixes https://github.com/eclipse-cdt/cdt/issues/689
* 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)
Recently new extensions were added to CDT for C++ modules in #422
At the time some test failures were not noticed. This change patches
those failing tests.
Fixes#454
Long ago in 334702ee05 generic types
were added. However in at least one place a previous assumption
that existed was broken. That assumption was the true
type of ResourceInfo.getTools() would be Tool[] as opposed to ITool[].
That commit broke it for ResourceConfiguration.getTools()
Internally in CDT ITool is in practice always Tool, and as a result
there are lots of downcast from ITool -> Tool. However ITool[] cannot
be downcast to Tool[] unless the original type was Tool[].
Instead we use Arrays.copyOf to copy the array into the correct
array type.
Steps to reproduce the problem now fixed:
1. Create a Managed Build executable project.
2. Open the properties window of the source file (as opposed to project)
3. At the Properties page, navigate to "C/C++ Build/Tool Chain Editor".
4. Click the "Apply" button.
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)
* recognize source file extensions ".ccm", ".cxxm", and ".c++m"
cmake 3.27 release notes: The "CXX" language now treats source file
extensions ".ccm", ".cxxm", and ".c++m" as C++.
Signed-off-by: 15knots <11367029+15knots@users.noreply.github.com>
importAll fails with error 'Project: .org.eclipse.egit.core.cmp already
exists in the workspace!' and no further projects are imported.
The fix is to not go into special directories .metadata and
.org.eclipse.egit.core.cmp. Moreover, importAll and removeAll do not
fail immediately if operation on a project fails,
instead it keeps on performing operation on all projects and at the end, headless
builder returns with error code if operation of any project failed
GCCToolChain.stripCommand() assumed that all resources are at the end
of the command, like in the old version of
GCCToolChain.getResourcesFromCommand() which was fixed in PR #311 (see
commit a89ce59df2). Now stripCommand() is in line with
getResourcesFromCommand().
