There were issues with how the Core Build calculated whether reindexing
was required due to compiler settings changes. Also if a source file
was built more than once in a CMake build, it ended up always
triggering a reindexing since the second instance looked like a
settings change. We now only use the last compile command for a file.
Change-Id: Icf2922e527ae20e0c3b0dae898d981d334013109
I added cmake arguments in the launch configuration for CMake
projects but didn't add it to the command line.
Also indexing wasn't working on my Mac. llvm-cc overrode the standard
local cc. Added the local compile commands if the toolchain is local.
Change-Id: I914c52dd42fbf84b87cd0e8c7504f024c2449a82
- add new FixitErrorParser that extends RegexErrorParser and is
used to replace the error parser for GNUCErrorParser
- add new FixManager class to bind a fixit message with its
problem marker
- modify ProblemMarkerFilterManager to register the last
accepted ProblemMarkerInfo for a particular resource so
the FixitErrorParser can find the last error marker for
the file that precedes the fixit message
- FixitErrorParser looks for fix-it messages and binds them
via FixitManager to the last error marker for the file
- add new Fixit class to contain the details of a gcc fix-it
- add new QuickFixForFixit which applies the gcc fix-it for the
file
- add new (.*) regex in codan.ui.checkers patterns that will
trigger before any other error and will look for the
fix-it message format
- change cdt.core to expose cdt.internal.errorparsers to
codan.checkers.ui
- change codan.core to expose codan.internal.core.model to
codan.checkers.ui
- fix CDocumentProvider.setOverlay method to not overlay
a CMarkerAnnotation that has a quick fix
- when deleting all C problem markers, also make a call
to FixManager.deleteAllMarkers() so markers aren't
left referenced
Change-Id: Ibf8ff7d8addb1bf092dc4ef35de0d92de0309589
See : https://www.eclipse.org/forums/index.php/t/1084842/
Original (WizardNewProjectCreationPage) getStartingPage() cast within
getMainPageData() method was obviously forcing first wizard page type
... provided basic trick is opening some opportunities more !
Change-Id: Ie9b7c4ef63040df6a419af8348f088be79cc2611
Signed-off-by: cartu38 opendev <cartu38.opendev@gmail.com>
Reorganize code and expose things for generic editor.
So far presentation reconciler only is ported.
Allows to right-click/Open with/Generic editor on e.g. Makefile.am and
see it in the generic editor. It is not as feature rich as the
specialized editors we have now but over time it should provide all the
features of them with significantly less code.
Change-Id: I72324b94ce08ab762979804914adbb1982c88198
Signed-off-by: Alexander Kurtakov <akurtako@redhat.com>
Generified, some lamnda conversions and some non-javadoc removal.
Change-Id: Ibf0493917ac3da7531de1ca591a9bfdc250ddf2a
Signed-off-by: Alexander Kurtakov <akurtako@redhat.com>
There is a collision in the ids of the pthread options,
"cdt.managedbuild.tool.gnu.c.pthread" is there twice. Change the ids to
be more in line with the other options.
Change-Id: Ice9d003b82b3740df6420811e90a2b157375c243
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
When a toolchain is selected along with its builder, the builder gets
matched to a “real builder” (ManagedBuildManager.getRealBuilder). If the
builder is abstract, the builder is not in the possible list of matches,
as implemented in Builder.getMatchKey. This causes
getCurrentBuilderCompatibilityInfo to return null which is not handled.
This patch changes the base LLVM builder to a non-abstract one, which
solves this specific NPE.
Also, in order to be more helpful to the user in case it happens to
another toolchain, a null check was added with an error message that the
builder is incompatible. Then at least, it is more clear that something
is wrong and the user can pick a different builder.
Change-Id: I4d26c568dfe6307b496719c10908a36933fd3ab8
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
This removes a lot of pom.xml from the source tree. This is using the
"POM-less" Tycho functionality.
See
https://wiki.eclipse.org/Tycho/Release_Notes/0.24#POM-less_Tycho_builds
One advantage of this is that you do not need to update the version in
the pom.xml when you change it in the MANIFEST.MF because the pom.xml is
automatically generated. This also reduces a lot of the duplicated
information and pom.xml repetition.
- Maven 3.3 and up is required.
- Only eclipse-plugins and eclipse-features can be pom-less.
Repositories, target and others still have pom.xml.
- New parent poms are added because a parent is necessary directly one
level above the plug-in/feature that will have its pom generated
- Some test plug-ins had to be renamed .test -> .tests because it's
required so that it detects that it's a test plug-in
- Some suites were renamed so that they all use the same consistent name
"AutomatedIntegrationSuite"
- Profiles were added for the more common test configurations. They are
activated by the presence of simple .properties files that only serve to
activate the correct profile. The profiles:
- One for UI tests (UI present and start in UI thread)
- One for SWTBot tests (UI present and do not start in UI thread)
Other test plug-ins that are too different are kept intact and still
have
a pom.xml
- Fragments are kept intact since they all have different target
platform configurations
Change-Id: I9d73380eb766f547830c552daf08053a30b1845c
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
This commit removes explicit source features and has tycho create them
automatically, along with all other source features that were not
previously defined. The logic to auto-generate is in the root pom.xml
For all pre-existing source feature, the name presented to the user has
been changed to use the default name used by Tycho, which is "Developer
Resources". This will provide a more standard user-experience with
respect to other source features built by Tycho.
Existing SDK features are kept for backwards compatibility.
All the names of the auto-generated source features that replace an
existing source feature have stayed the same except for the
'testsrunner' feature; for that one name change, a p2.inf file is added
to allow upgrading from the old named feature to the new named feature.
Change-Id: Ie632e798c93898fd828f88df4983fc43e2749d22
For example, opening the CMake property page, there was a missing
message for the cmake-ui button.
Change-Id: I126fe1cb6e290edc289a2dade44500dd35ed1207
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Pre-build will always run in parallel to compilation of source files
unless each and every source file depends on pre-build. Also, when
parallel build was enabled, the "Make build target" under "Workbench
Build Behavior" was ignored. Instead of doing make -j all, Eclipse ran
make -j pre-build main-build. While the intentions are good, make will
attempt to build pre-build and main-build in parallel for previous
stated reasons.
This patch changes two things:
1. Eclipse will consistently respect the "Workbench Build Behavior" for
both single- and multi-process build.
2. The generated makefile is changed to guarantee pre-build is run
first.
Changed from
all: pre-build main-build
to
all:
$(MAKE) --no-print-directory pre-build
$(MAKE) --no-print-directory main-build
Change-Id: Icf3a1057ee3b3cc8a04a433820492a4f469e17dd
Signed-off-by: Morten Kristiansen <millibit@gmail.com>
Make sure Core Build handles the properties set by these tabs
correctly. A bunch of string externalization too.
Change-Id: I54a61b4d2520a0952c43608169747e792826062e
This change overcomes the Cannot run program "rm": Command line
too long error when there are hundreds to thousands of files.
This change only applies to the interal builder.
Change-Id: Idc32067e27d76e3b438b2b1a07376859c7c8d1e4
Handle failures when trying to find the resource at the end of
a command line when it's not really a command line.
Change-Id: I7dc94a2c45c758248d0402c253e077142ee050e3
Unify launching for projects that use the new Core Build system.
Starts with CMake projects. We'll do Qt projects next.
Change-Id: I14af8e99decd54cc6548095b3ad3e054c550aea2
For ESP8266, I want to auto discover the toolchains and friends
installed into Eclipse. I also want to handle toolchain files
manually added by the user. Adding providers and listeners.
Adds prefix to gcc commands. Makes CMake config provider for Local
only. ESP8266 has it's own launch config. Add build output to the
build config model. And fix up output folders.
Change-Id: I682c3d08898e5ca275d07f8bb63c6ec1c7605a81
Right now launch configuration delegates need to know too much about
the specific build system for a project (cmake versus qt, for example)
Start decoupling this and test out the theory with CMake.
Change-Id: I8a362f16cddca77b37a5ab5920ee19318035d478
Use launch target os and cpu arch properties to pick toolchains and
toolchain files. UI to add toolchain files. And build support.
Also some clean up of Qt as I found bugs.
Change-Id: Icd1da43460b5954eea15e95ed8ec27850fc4e54e
Reads the compile_commands.json file and feeds the commands into
the processLine method of the build config which creates the scanner
info. The scanner info is cached in memory and stored in the
metadata directory.
Change-Id: I8b04e661dfe767904d1c10119c07167fee8cd7e4
