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
This provides the shared pre/post condition assertions to
help make sure tests are running in a clean environment.
If I had time I would convert all the tests to BaseTestCase5
which is JUnit5, but I only did the tests that had something
wrong with them.
Part of #117
Instead of using assertTrue, but assertEquals we get nice
error messages that show the contents of the collections.
Using assertEquals(List.of() instead of assertArrayEquals(...
because that gives nicer error messages.
Part of #117
The test "abused" the JUnit3 ability to control test order and
required all tests to run in the given order to work.
Refactored the test to remove all redundant try/catch and
provide a more traditional flow.
Part of #117
While it may be that the tests don't directly rely
on JUnit5, the IDE requires JUnit5 in the classpath
or else the launch config doesn't work with this error:
Cannot find class 'org.junit.platform.commons.annotation.Testable'
on project build path.
Part of #117
Having the test suites means that tests run multiple times
when running in the UI. Most suites just ran the tests in
that package, so their value, especially with the transition
to JUnit5 is minimal.
Note that the suites are not used when running build
with Tycho/Maven
Part of #117
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.
* Add ManagedBuildManager#createConfigurationForProject()
This should allow ISV's to create MBS based project with a
vendor-specific build-system ID without using internal API.
Update New & Noteworthy
Signed-off-by: 15knots <11367029+15knots@users.noreply.github.com>
Changed the execute to take the cwd to run the command in and
clean up the related code, including some error message
handling and removing some redundant code.
Fixes#125
testAbstractBuiltinSpecsDetector_EnvChangesGlobal did not properly clean
up after itself, which caused
testAbstractBuiltinSpecsDetector_EnvChangesConfiguration_1,
testAbstractBuiltinSpecsDetector_EnvChangesConfiguration_2, and
testAbstractBuiltinSpecsDetector_EnvChangesGlobal to fail when run for
the second time in the same session.
Running tests twice is not useful, but happens in Eclipse with a launch
configuration set to run all tests in
org.eclipse.cdt.managedbuilder.core.tests/tests - once directly and once
through AllLanguageSettingsProvidersMBSTestSuite. I have not found any
way of running every test exactly once in the GUI.
Each command should have it's own command launcher. The alternative is
to ensure that the previous command has finished prior to launching the
next one, but that's harder to acchieve as it's up to the consumer of
Builder to fullfill.
Contributed by STMicroelectronics
Change-Id: I17038220ccd7c1767328ecfce92f28d8205c1d56
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
