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>
Eliminate ResourceException by avoiding processing a deleted source
folder resource as a modified resource.
Change-Id: Icfa10040d4d3c6c06b2a4c040e7b632e94dff324
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
Guard against NPE. Full cause needs to be investigated but with this
check the behaviour is no worse than before in these cases
Change-Id: I27ed2cd915e21fca2ef07335820d9e2496c1c51d
On Windows, the TabFolder and TabItem classes does not follow the
themeing in Eclipse. As a result, the tab selectors will be drawn with
the light theme while the rest of the Eclipse UI is in dark theme.
Contributed by STMicroelectronics
Change-Id: I9169c9e01f8c9a3af7b6bb6d1c673a043735e7e9
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
We eliminate unnecessary command line pattern attributes that were
overriding the default pattern provided by
org.eclipse.cdt.managedbuilder.internal.core.Tool which now includes
${EXTRA_FLAGS}.
Change-Id: I8c4e8e613599e71e31e390f56319bacfd0329ab2
The GCCBuildCOmmandParser expects the compiler tool to be exactly what's
included in the pattern, i.e. a prefixed toolchain (for example
"arm-none-eabi-" would not match.
Contributed by STMicroelectronics
Change-Id: I9e6b83509ecac9c382f565e5c7b737d12398a196
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
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
Fixing the issue where circular dependencies cause stack overflow.
Change-Id: I4ca87eb4e8ccb82b25f85d1cea04fc0d4ddd60c0
Signed-off-by: Umair Sair <umair_sair@hotmail.com>
The colors chosen were based where possible on the colors of the CDT
main editor (org.eclipse.cdt.ui/css/e4-dark_cdt.css) for similar
syntax/semnatic elements.
Change-Id: Iea6ccb481b8d1b16aa2d6dda16e44b2512662fa0
If a user set the make arguments manually to what the automatic
arguments would have been if enabled, they would be discarded. This
change does not do that bit of magic anymore because the user
now (since Bug 568397) edits the build command and arguments
separately so less magic needs to happen in the code.
This is a follow-up to Bug 568397.
Change-Id: Ie8f51cbb86133fc4a9506913743613712e93d881
and:
- bump versions of all the docs plug-ins.
- improve comment so that next person can do it more easily
- change to using https in the URL
Change-Id: I62bd970f03e1ce081d4655ddbf6c742be2623acd
Include the top-level subdir.mk only when one was actually generated
(i.e. when there are source files there), just like for all other
subdir.mk, otherwise a stale one from earlier when there were source
files that have since been removed may be picked up, causing "No rule to
make target" errors.
In some cases (from bug 303953), the removal would be noticed and the
stale subdir.mk be overwritten by a correct empty one, avoiding the
error, but not in the following cases:
- When CommonBuilder.performCleanning() decides that a full rebuild is
needed, regenerateMakefiles() is called instead of generateMakefiles(),
which doesn't get the delta.
- When the refresh in which Eclipse notices the removed source file
happens as part of a build (one that probably failed because the
makefiles weren't updated yet), the next build after that apparently
does not get the delta containing the removal anymore.
Change-Id: Id15b424f02dd5c513d2124620c0c8699d61874fd
Signed-off-by: Christian Walther <walther@indel.ch>
Several parts of makefile output were generated by iterating over
HashMaps, which do not have a deterministic iteration order. Use
TreeMaps instead to output in sorted order. This is possible now that
the API function with return type HashMap is no longer public API and
can be changed to return Map instead.
Benchmark files for affected tests are updated to the new ordering.
This would not be strictly necessary: the tests would also succeed
without, since org.eclipse.cdt.managedbuilder.testplugin.
ManagedBuildTestHelper.compareMakefiles() uses a reordering-tolerant
comparison. However, recording the new (now hopefully stable) order
makes future development on makefile generation easier by avoiding
spurious diff output when tests fail due to changes to other parts of
makefiles.
Change-Id: I20f2e51bd5b9e3bcc5da245d781ca5b4a34fc0b2
Signed-off-by: Christian Walther <walther@indel.ch>
This fixes a small and rarely hit in practice regression regarding
nondeterministic ordering in makefile output introduced in 15c29eb (bug
505882).
Multiple values for a build output variable were previously output in
definition order. Now they are generated by iterating over a HashSet,
which does not have a deterministic iteration order. Use a TreeSet for
output in a consistently sorted order instead.
Output variables with multiple values are rare (most tools generate one
output file of a particular type) and this case was not exercised in the
existing unit tests. Modify one such that it does (even if in a somewhat
contrived situation). Of note, ${OUTPUT} cannot be used in the
commandLinePattern for such a tool because it squashes the multiple
values into a single quoted file name - misuse ${FLAGS} instead.
Change-Id: Iaa28525c21d74c87dd4d72a03e334ed0e5576727
Signed-off-by: Christian Walther <walther@indel.ch>
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
If these tests fail, they cause a series of metadata corruption that
will render most/all test executed after as unreliable. Usually, there
is about ~150 test cases that fail without reason when one of these
fails.
Contributed by STMicroelectronics
Change-Id: Ic71ace8b6a55c49dd729d40385b245f12dbd6d85
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
The interface has no use as it's hardcoded to be an instance of
ManagedBuildGnuToolInfo in the GnuMakefileGenerator anyway.
Contributed by STMicroelectronics
Change-Id: I0e9130ef485d103e7114e0d122015c062253b4bb
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
To avoid errors like "Command line too long" when removing build
artifacts, split the clean command on multiple lines. In order to
properly handle whitespace etc, generate a new clean target in each
subdir.mk with the explicit list of files to remove in that directory.
The command should be splited on a sane length, 6000 is used in the
internal builder, so reuse that limit here.
Contributed by STMicroelectronics
Change-Id: I843e1ac896076d279173c421210b72f4a325296f
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
One more place where the GnuMakefileGenerator is instanciated that
should have been changed in previous commit.
Contributed by STMicroelectronics
Change-Id: Ib89d5e77cbdd2148723b9b1a80cafb72d35390a4
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
The GnuMakefileGenerator is a huge file that needs lots of fixes.
However most of the time to implement the fixes are taken up trying
to not break API. Most extenders of CDT provide their own
implementation of GnuMakefileGenerator by copying the CDT one
and modifying it. Therefore CDT is going to take that same
approach internally and leave the existing GnuMakefileGenerator
in its unmodifiable state.
Change-Id: I12fafb5e347112648a02d4593267bd88a47b5c88
