RE: [cdt-dev] CDT Conference call - Build Model Docs

["Alain Magloire" <alain@xxxxxxx>]

> All,
> 
>   My apologies for not getting this out sooner;
> I hope that folks will have a chance to review
> this before the conference call.
> 
>   I've put the java docs for the work I've been
> doing on an initial build model implementation
> on line at:
> 
>   <http://www.oneparticularharbor.net/sam/cdtdoc/>
> 
>   The docs are available both for download (as
> zip files) and for online browsing.
> 
>   Please keep in mind that this is a work in
> progress.  There are some issues that were raised
> in the build model discussions that I know aren't
> addressed.  I think that once we have a basic model
> in place, it will be easier to visualize how/where
> some of those addition features can be merged
> into the model.



First, very interesting work.

After a bird eyes view, I got some questions to help me getting a better understanding.
Feel free to answer them in different emails.  Thanks again for the API templates.

== Scenario 1: Existing proprietary builders.
In a previous email from Sky M. @ rational, he outlined some of the things the build model
should accomodate and one of them was cooperation with others.
For example, for the QNX IDE, qnx C/C++ project,  QNX provides a builder
for the project that has a very good knowledge of the way things should be compile
(Drivers, resource managers etc ..) and even on where things are in the filesystem.


Sky's vision below(he could correct me, if I missed the point 8-)

                                +=============+
                                | Build Model |
                                +=============+

         ^                  ^                   ^                    ^
         |                  |                   |                    |
  +=============+  +==================+ +================+  +==================+
  | QNX Builder |  | Tensilica Builder| | Tymesys Builder|  | CDT Default Build|
  +=============+  +==================+ +================+  +==================+

It was not clear to me how those other builders can plugin within the CDT.
Unless the answer is: if you use the IDE you got to use the Build of the CDT.

== scenario 2: Existing projects
Lots of talk about usability, where new users hit a brick wall
i.e. they have to put up with arcane Makefiles etc ..  all true.
However what about the flip side of the coin, for example we have customers with
very complex build procedures, some simply defy sanity(for some histerical raisin).
Not suprising, those customers were quite happy with the default CDT builder 8-)

It would be nice for them be able to use the IDE even if they do not have
the bell and wistles of the super duper IDE builder.
It will probably be an incentive to migrate in the long term.

So we can say to clients: "Oh! you have a monstruous project, a build develop by
summer students and you are in a time crunch and can not do the conversion? Ok
we can give you an adapter for the IDE that will spawn your shell scripts, minimal
and you may loose some features but you can get to work right away."

== scenario 3: Information for other modules.
For example, the debugger needs to know the src paths for the sourceLocator to find
files when stepping.  The parser may need some macros, definition to do parsing
correctly.  The indexer, search, refactor may also need the include paths, in C++
the entire definition of the class can be inline in a header, the class definition
is needed to do correct code complete/assist.  Some work was started in the 
ICBuilder but we did not have a chance to refine.

== scenario 4: Extension points.
Can it(should it) be possible to overload the entire Build Model?
Where the other extension points?  for example for the error parsers ?

== scenario 5: Integration with the current CDT
In the CDT core there is a framework for extension points it is save in the
project, in a ".cdtproject" file.  The ".cdtproject" file is somehow equivalent
to the ".project" but for the CDT so it is possible to export/share information.
For example when checking out a C/C++ Project, the binary parser type, build model type
etc .. can be shared.  Here is an example of what is generated now:

<?xml version="1.0" encoding="UTF-8"?>
<cdtproject id="org.eclipse.cdt.core.make">
    <extension id="org.eclipse.cdt.core.makeBuilder" point="org.eclipse.cdt.core.CBuildModel">
        <attribute key="command" value="make"/>
    </extension>
</cdtproject>

Sharing properties/settings(via cvs or other means), seems to be important for some of our
customers .. they even ask to share breakpoints ... sigh ..