[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] API for external tools
|
Hi Sky,
Can you say more about how your tools currently work with the JDT? You
mentioned that your requirements fall under the four broad categories of
source code, build, deployment and debug. Does JDT provide consumer,
supplier and controller APIs for each of these areas?
I agree that it is better to extend the CDT than have a profusion of
derivative works. I also agree that it's better to have a single CDT
instance with multiple tools rather than in different instances. We need to
make the CDT extensible in enough areas to allow venders the control and
flexibility that they need over the core CDT. Identifying these key areas
are necessary, so the categories you mention certainly helps.
You wrote:
>2. It should be possible for a customer to use the CDT with an existing
>C/C++ command-line toolchain (compiler, linker, and possibly debugger).
This
>is, to some extent, already possible. The CDT build assumes a make build
>environment, so the customer can create makefiles to use whatever build
>commands they want.
By default, the CDT builds and cleans by invoking "gmake" and "gmake
clean". When a new C project is created, the wizard picks up this default
from the preferences. The build properties for a project can be changed
when the project is created or after using the properties dialog. Users
can also change the preferences so that some other means of building is the
default. So if a user wanted to use some program like "build.exe" to do
his/her builds, he/she can change the build properties to use that instead
of gmake.
> I believe the CDT can even be configured to parse the
>build output.
This is true. There is a file that defines a bunch of
regular-expression-based patterns that can be used to interpret the output
of different programs. It's used not just for build, but for any program
that has interpretable output, such as "grep".
>Other requirements that I will communicate in detail in
>another email lead me to think we need to provide some more build
>configuration capabilities right into the CDT.
What build capabilities are you thinking? Sort of like a "supplier" API
for contributing your own builder? Eclipse already provides some support
for this kind of thing. Every project has a list of builder specs and
natures. You can add, edit or remove build specs and natures using
Eclipse APIs. When you do an Eclipse build, Eclipse decides which
builders to call based on how the project was configured. For example, we
provide an action delegate, "Support C/C++", that lets you take a non-C
project and makes it a C project. To handle setting up natures and
builders, we use the following code:
...
// add build spec
String builderName = "org.eclipse.cdt.cpp.ui.cppbuilder";
IProjectDescription projectDescription =
project.getDescription();
ICommand command = projectDescription.newCommand();
command.setBuilderName(builderName);
ICommand[] commands = projectDescription.getBuildSpec();
ICommand[] newCommands = new ICommand[commands.length + 1];
System.arraycopy(commands, 0, newCommands, 0,
commands.length);
newCommands[commands.length] = command;
projectDescription.setBuildSpec(newCommands);
// specify nature
String[] natures = projectDescription.getNatureIds();
String[] newNatures = new String[natures.length + 1];
System.arraycopy(natures, 0, newNatures, 0, natures.length);
newNatures[natures.length]
= "org.eclipse.cdt.cpp.ui.cppnature";
projectDescription.setNatureIds(newNatures);
project.setDescription(projectDescription, null);
...
>Integration of existing debug
>tools may be more difficult. The current CDT provides a GUI that
>communicates with gdb (using the MI interface now?). It should be possible
>to publish a standard "debug" API that would allow a customer or other
>vendor to integrate any debugger by supplying an adapter. If the API is
>simply gdb's MI interface, that would probably be ok, as long as another
>vendor can plugin an MI<->myDebugger adapter. It should also be possible
for
>a vendor to plugin their own debug UI. This should be in addition to, not
>replacement of, the existing debug UI.
As for the debugger control integration, I'm not sure whether the
integration needs to be at the CDT debugger level or at the Eclipse core
debugger level as the behaviour of debuggers for different languages are
fairly common (step, set breakpoint, jump, etc.).
____________________________________
David McKnight
Linux AD, CDT Development
Phone: 905-413-3902 , T/L: 969-3902
Internet: dmcknigh@xxxxxxxxxx
Mail: D2/ 329/8200/TOR
____________________________________
"Matthews, Sky"
<smatthew@ratio To: "'cdt-dev@xxxxxxxxxxx '" <cdt-dev@xxxxxxxxxxx>
nal.com> cc:
Sent by: Subject: [cdt-dev] API for external tools
cdt-dev-admin@e
clipse.org
05/02/2002
04:30 PM
Please respond
to cdt-dev
dmcknigh@xxxxxxxxxx wrote:
<snip>
> Now we need to know what's missing. In particular, we need to provide
> functionality that meets the requirements of external providers, where
> reasonable. There are a lot of questions that this raises. To name a
> few:
> -What do 3rd parties want to be able to use CDT for?
> -In what form should output from consumer APIs be?
> -How are providers' tools used with other non-CDT technologies?
> -Where are the primary tooling interests of the 3rd parties? Local,
remote or both?
> -What are the practical ways to categorize and organize APIs?
>
> In this thread, I hope we can generate some good discussion and maybe
> answer some questions. It is critical that we hear from 3rd parties,
> themselves, but it would be nice to hear from other interested parties as
> well.
I would like to take a shot at communicating some of our requirements here.
Some of these requirements may already be satisfied by the current
implementation. I have tried to point this out where possible, and in some
cases, how the current implementation may not be sufficient. In other areas
where our requirements may be unique, we would like to help contribute to
address the requirements. I anticipate that because we are fairly late in
the 2.0 cycle, most of these requirements will not be addressed until the
next iteration.
Our requirements fall into 4 broad categories, so I will follow-up with a
separate email on each topic to focus the discussions. These areas are:
-source code (object model, editing, etc.)
-build
-deployment
-debug
We have a mixture of "consumer", "supplier" and "controller" requirements
in
each area.
In answer to the questions above:
> -What do 3rd parties want to be able to use CDT for?
see use case below as an example. We expect that our customers will be
using
the CDT, and therefore we want our tools to work with the CDT in many of
the
same ways they work with the JDT. The most fundamental requirement is that
we would like to see other vendors create plugins to extend the core CDT to
support new environments. We do not want to see a profusion of derivative
works.
> -In what form should output from consumer APIs be?
I'm not sure I understand this question, but as long as there are APIs that
expose the object model(s) for other tools to extract information from or
modify (e.g., the JDOM API on the JDT side), then that should be
sufficient.
> -How are providers' tools used with other non-CDT technologies?
This is probably too detailed to provide here. If you are interested in
seeing demos of current product interworkings, I can arrange that.
> -Where are the primary tooling interests of the 3rd parties? Local,
remote or both?
Both, but primarily local.
> -What are the practical ways to categorize and organize APIs?
I believe that, as much as possible, trying to organize things similar to
the way it is done in the JDT is very useful, both in terms of
understanding, and building tools that have to work with both Java and C++.
Symmetry is good.
We have a few "higher-level" requirements on the CDT that I would like to
raise before I get into details.
1. It should be possible to support multiple C/C++ tools from one instance
of Eclipse. We believe that a number of developers work in multiple
environments (e.g., native Linux development and embedded target
development). The developer should not have to install Eclipse-based tools
in separate instances of Eclipse.
2. It should be possible for a customer to use the CDT with an existing
C/C++ command-line toolchain (compiler, linker, and possibly debugger).
This
is, to some extent, already possible. The CDT build assumes a make build
environment, so the customer can create makefiles to use whatever build
commands they want. I believe the CDT can even be configured to parse the
build output. Other requirements that I will communicate in detail in
another email lead me to think we need to provide some more build
configuration capabilities right into the CDT. Integration of existing
debug
tools may be more difficult. The current CDT provides a GUI that
communicates with gdb (using the MI interface now?). It should be possible
to publish a standard "debug" API that would allow a customer or other
vendor to integrate any debugger by supplying an adapter. If the API is
simply gdb's MI interface, that would probably be ok, as long as another
vendor can plugin an MI<->myDebugger adapter. It should also be possible
for
a vendor to plugin their own debug UI. This should be in addition to, not
replacement of, the existing debug UI.
Here is an example use case that I hope will illustrate our objectives for
using/working with the CDT. The workflow description in the use case
obviously makes assumptions about how the tooling will work. The final
tooling may actually work much differently but still meet the intended
usage
requirements. Apologies for the long use case, I thought it easier to
understand the intent with one end-to-end scenario than many small use
cases.
----
Use case: user models an application in UML for deployment on Linux and QNX
(the setup may not be realistic, I'm just using it for illustrative
purposes)
pre-conditions:
-user has a Windows workstation
-user is working on complex distributed application, a portion of which is
running on a processor running QNX, another portion of which is running on
a
multiprocessor Linux server
-user has installed Eclipse + the CDT + the QNX C/C++ tools (assume these
are built as CDT extensions for the purposes of this use case) + a modeling
tool
Main Flow:
0. User starts Eclipse
1. User creates a C/C++ project for the application component that will run
on Linux (we'll call it project 'L') - project L is stored and built
remotely on the Linux machine (the 'remote' development case)
2. User creates a C/C++ project for the application component that will run
on QNX (we'll call it project 'Q') - project Q is stored and built locally
on the Windows machine with a cross-compiler for QNX targets (the 'local'
development case with a cross-compile twist)
3. User creates/imports some source code into project L
4. User creates/imports some source code into project Q
5. User creates a 'build target' in project L
Note: a 'build target' is a new concept that does not really exist (?) in
the current CDT - it roughly corresponds to a makefile: a specification of
a
buildable entity like an executable together with the rules that (we'll
ignore details of hierarchical makefiles and other complicated build
scenarios for the purposes of this use case). I'm not necessarily proposing
the name 'build target' here, just using it as a placeholder - hopefully
the
concept is clear.
6. User edits the build target specification to select the build toolchain
from a named set (in this case, let's assume {GNU Windows, GNU Linux, QNX}
is the set of named toolchains available.
7. After selecting 'GNU Linux', the user chooses the files to be included
in
the build, enters the name of the executable, and selects some compilation
options from a list (e.g., is able to select a 'debugging' option instead
of
typing '-g' in a flags field).
Note: I'm not entirely sure how the remote Linux development changes this
workflow.
8. After completing the edits of this build target, the CDT generates a
makefile.
Note: The details of the makefile generation should probably be handled
through an extension plugin rather than as a core function - different
toolchains may require different styles of makefile.
9. User performs similar 'build target' actions in project Q (selecting the
QNX toolchain this time)
10. User creates a UML model in project L
11. The modeling tool extracts the code information from the project and
creates a UML model of the code
12. The modeling tool extracts the build information from the project and
creates a UML model of the build (a 'component' diagram in UML terminology)
13. User notices the wrong return type on an operation and corrects it on
the UML diagram. The modeling tool updates the corresponding source code
file.
14. The user selects the UML component that represents the 'build target'
and chooses 'build' (an action exposed on UML components). The UML tool
then
calls the CDT API to build the selected 'build target' in the project.
15. The CDT calls make (using settings associated with the selected
toolchain). The build output goes to an output window.
16. A compile error appears during the build, and the compile error is
logged in the task list (as with the JDT). The user double-clicks on the
compile error (in the task list) and the source code editor is opened at
the
error location.
17. The user also builds project Q
18. The user selects the built executable from project Q and clicks the
'Run' button to download the app to the QNX target and run it.
Note: this implies some association between the executable and a deployment
tool (since 'Run' for a QNX executable is much different than 'Run' for a
Linux executable). I'm not sure of the details of how the run action is
handled in Eclipse. There are several possible ways to handle this:
1) details of the Run method could be user-selected after they hit run, or
2) they could be automatically set for the given executable by a plugin for
the particular toolchain, using a CDT API. This assumes that a plugin can
contribute some kind of Run action handler for particular resources.
19. The user then selects the executable from project L and runs it to test
the complete system.
The main points to extract from this use case are:
-That it should be possible to support multiple C/C++ toolchains from a
single instance of Eclipse/CDT. (in fact, within any given project, I
should
be able to create different builds, for example: 1 for a QNX simulator
build
and 1 for an actual target build). In the workflow, I made a supposition
that there is some kind of configuration that defines a named 'toolchain'
(could be through an XML file or through a plugin), and which then exposes
further properties/settings specific to that toolchain. As mentioned
before,
the current CDT does allow this, but the mechanisms provided are arguably
not very user friendly (unless you are very comfortable with
autoconf/automake). (these are primarily supplier APIs)
-That there probably needs to be a representation of builds (makefiles) to
enable this, and that furthermore, the CDT needs to expose the build
properties through an object model to allow consumer tools to get
information about it and even modify it. (these are primarily consumer
APIs)
-That there needs to be a way to associate deployment/run commands with the
build result (i.e., the executable). Preferrably, a vendor plugin can
contribute vendor-specific deployment commands and properties. (these are
primarily supplier APIs).
-That the CDT needs APIs to allow other tools to automatically invoke CDT
actions, such as build and run. (these are controller APIs)
I will try to elaborate more detailed requirements in each of the primary
categories identified above in the next few days.
Regards,
-Sky Matthews
Rational Software
smatthews@xxxxxxxxxxxx
original message:
--__--__--
Message: 1
To: cdt-dev@xxxxxxxxxxx
From: dmcknigh@xxxxxxxxxx
Date: Thu, 18 Apr 2002 17:51:23 -0400
Subject: [cdt-dev] API for external tools
Reply-To: cdt-dev@xxxxxxxxxxx
There have been a few informal discussions about how external tool
providers should communicate with the base CDT. We need discuss these API
issues here so that all interested parties can contribute to the
requirements and designs.
External tool providers might want to be able to do various things as
consumers, suppliers, controllers or some combination of the three.
Examples of things
...consumers might want to do:
-get at parse information for use in some external tool
...suppliers might want to do:
-contribute an alternative parser to the CDT
-extend an existing CDT tool to provide richer functionality
-provide actions to act against CDT resources and artifacts
...controllers might want to do:
-explicitly control the build
-explicitly control a debug session
There are already a few mechanisms in place that 3rd parties can use to
communicate with the CDT:
1) Eclipse Action Contributions
-to provide object actions against resources (we support this for
local but not remote projects)
-we still need to provide this kind of support for working
against C artifacts
2) Miners and the DataStore Framework
-to get remoteable (works remotely as well as locally)
integration with the core tools and the UI
-miner contributions automatically sufaced by views
-we still need to provide better way to allow 3rd parties
configure which miners get loaded
3) some APIs
-there are some UI APIs that let you do some basic things, but
they aren't really designed for external use
-there are also ways to integrate with the DataStore Framework
from the UI side
Now we need to know what's missing. In particular, we need to provide
functionality that meets the requirements of external providers, where
reasonable. There are a lot of questions that this raises. To name a
few:
-What do 3rd parties want to be able to use CDT for?
-In what form should output from consumer APIs be?
-How are providers' tools used with other non-CDT technologies?
-Where are the primary tooling interests of the 3rd parties? Local,
remote or both?
-What are the practical ways to categorize and organize APIs?
In this thread, I hope we can generate some good discussion and maybe
answer some questions. It is critical that we hear from 3rd parties,
themselves, but it would be nice to hear from other interested parties as
well.
____________________________________
David McKnight
Linux AD, CDT Development
Phone: 905-413-3902 , T/L: 969-3902
Internet: dmcknigh@xxxxxxxxxx
Mail: D2/ 329/8200/TOR
____________________________________
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
