launchConfigAdded becomes pretty important. Requires providers
to be able to find descriptor and target from the incoming
configuration if they own it. Also added handing for a default
when the target is null.
removed ownsConfiguration in providers since the launchConfigAdd
does that by returning false.
Added enablement for config providers, but that will need work
and some default property testers for it to be useful.
For the correct way to add in a config provider, check out the
Arduino change for this API at:
https://git.eclipse.org/r/#/c/49029/
Change-Id: I46b194a933c846d7d3e4eea8a0213c4ec324816f
that was causing a CompositingNotImplementedError
Change-Id: Ida8e09dbc438f23ed3187f97429efe1a31b4d037
Signed-off-by: Nathan Ridge <zeratul976@hotmail.com>
Also added the command shell console to the cdt 4.5 target so we can
test the Arduino command shell.
Change-Id: I185f9b39d23a6718204112e1fd4388c2458f7e5e
- fixed tests and added tests for previous API changes
- fixed unsafe call of provider methods without catching exceptions
- added description of priority attribute in the extension point API
- fixed default return values in DefaultLaunchConfigProvider, in case it
is extended
- removed unused import
- fixed per target provider to support persistance
- added test for per target provider
Change-Id: If08b18b939e86757108a800d1092a62621a8c7d0
- Change to use the launcher plugin instead of the internal
Activator from org.eclipse.linuxtools.docker.ui
Change-Id: I55c5ee8a70714a76543b6deb029003c9d8a7862c
(cherry picked from commit e51f7256e5)
we missing API to notify provider that configs are added/changed.
it required to keep internal provider map in sync, i.e. restore
the state of config/descriptor map on startup for example.
Change-Id: I3af24a21d5d41084f85731f6da2f7aca2df81f1c
line_brkpt_co.gif is edited version of function_brkpt_co.gif
Change-Id: Ifb74e86e1033a11e319c643f9ba1a7034a983173
Signed-off-by: Jonah Graham <jonah@kichwacoders.com>
- creating a Container launch configuration in Debug Launch
Configurations View does not work
- problem is that the ContainerTab was not setting the connectionUri
by default
- also set Remote Attribute which is needed for Container launch
to properly connect with gdbserver in Docker Container
Change-Id: Ifb25b1cfcc8d4e3ac2c67b60a0072463774b108f
This patch creates a product so that the stand-alone can be downloaded
without
the rest of the C/C++ EPP. It also makes it easier to use because the
user only
has to launch the executable, just like a regular Eclipse instead of
finding
the script.
To try the RCP:
mvn clean package -Pbuild-standalone-debugger-rcp
The result (tar.gz) is available under
debug/org.eclipse.cdt.debug.application.product/target/products
Once extracted, it can be started just like the normal script:
./cdtdebug -e myexecutable
Change-Id: Ifb849af8a8f2ec03abcae57cf43d57cde2333759
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
- use the new docker tooling plug-ins to launch and debug
CDT C/C++ applications in docker containers
Change-Id: I30689255a3443ce6d49f937f5e2506d86452915b
It's too hard to replicate the entire debug platform launch sequence
in order to insert the target this way. We'll need to come up with
something better if we want to share launch configs between targets.
But that will have to wait until Neon at the earliest.
Change-Id: I208eed527961e172316f0b12b869be5665a6aca5
Also adds a tighter check for ownsConfiguration based on class name
of the provider that created the config.
Change-Id: If197246af0906cb5af92819171ee97dc7cd30bee
WTP needs a new config for every target. That breaks our architecture
of one config per target type. But that's actually already broken
since we can't really get the proper target to the launch config.
Depending on active, we always hoped the target didn't change, but
it can. So one config per target is correct anyway.
Change-Id: I14ba8413b9494a13f3496eed5535debbc330a56c
