* 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().
Allows the GNU tool prefix to be specified by a CDT build variable.
Modifies the Cross GCC toolchain description to provide the GNU tool
prefix.
Part of #361
Fixed the problem for Core Build Makefile projects that the output
binary could not be found during launching when the user set the
Build Output Location to "Build in project directory".
The project was only looking for binaries in the "build" folder.
The old method assumed all resources were at the end of the line,
optionally followed by option -o.
Now the complete line is scanned for valid resource file extensions.
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>
Without this change when the project is not a "hasTargetBuilder" then
the projectMap will contain an entry mapping the project to
an empty set of makefile targets. So when we get a project added,
make sure to re-read the target settings by clearing the cached
versions.
Fixes#244
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.
This resolve the following exception during the build:
!ENTRY org.eclipse.ui.ide 4 4 2022-11-11 09:45:42.503
!MESSAGE Entry is outside of the target dir: ../
!STACK 0
java.io.IOException: Entry is outside of the target dir: ../
at org.eclipse.ui.wizards.datatransfer.ZipFileStructureProvider.initialize(ZipFileStructureProvider.java:190)
at org.eclipse.ui.wizards.datatransfer.ZipFileStructureProvider.getChildren(ZipFileStructureProvider.java:113)
at org.eclipse.ui.wizards.datatransfer.ImportOperation.importRecursivelyFrom(ImportOperation.java:781)
at org.eclipse.ui.wizards.datatransfer.ImportOperation.execute(ImportOperation.java:385)
at org.eclipse.ui.actions.WorkspaceModifyOperation.lambda$0(WorkspaceModifyOperation.java:110)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2380)
These binary parsers have been slated for deleting for
a while and are replaced with 64-bit compatible
versions.
Some methods still refereneced the 32-bit variants
and have been updated to the fully functioning
64-bit variant.
The older parser IDs are preserved (forever?) so that
old projects can be opened without needing to do anything.
The IDs now point at the new implementations.
See also Bug 562495
