Re: [cdt-dev] Build model proposal

["Alain Magloire" <alain@xxxxxxx>]

> 
> All,
> 
>   Following is a proposal for dealing with the build model in the next
> major CDT release.  It's based on, but not identical to, work we've done
> here at TimeSys for our soon-to-be-released TimeStorm IDE.
> 
>   I know that others (QNX and Tensilica, in particular) have also done
> work in this area.  From the recent flurry of messages on the mailing
> list, I think that we all have fairly similar (or at least, compatible)
> ideas about the build model.
> 
>   One issue that is not addressed in this proposal is build script
> generation (ant build files, Makefiles etc.)  I think that given a good
> build model, build script generation becomes a fairly straightforward
> process, and one that can be discussed seperately once the abstract =
> build
> model is defined.
> 
>   I look forward to your comments... hopefully, even if this model is
> waaaaaay off the mark, it will at least get us all to start looking at
> and discussing the details of the build model.
> 

It certainly has a lot of similarities to what we had in mind.
Glad to see you took the lead on this.  A few comments:

The CDT is a framework, meaning it defines a set of interfaces for
different modules.  The interfaces are "contracts", it does not
matter how or who implements them.

CDT -
    - Builder
    - Indexer
    - Target
    - Core Model(CDom, binary parsers)
    - format
    ... etc ..

The CDT provides a "default" implementation for the modules, that
could be override.

> ------------------------------
> Proposal for a CDT Build Model
> ------------------------------

In this case, your proposal, will transform to a set of interfaces,
that will be the "contract" for the build model.

So, let say QNX, when it sets itself as the Builder for this project
can respect the contract when other modules ask for information.

For example, someone sets SlickEdit as the CoreModel(CDOM)(because they have
great C/C++ parsers) it can ask for defines parameters from the builders whithout
caring that the builder is actually a QNX Builder.
 
It is probably impossible to come up with a general model that will satisfy
all ways of building, whithout being too complex or overkill.
Another way, would be to query the build model implementation for advance features,
"do you supports build staging?", "can you do XXX?"



We can probably work with most of what you propose except the FMM,
if you need to transform a *.c or any other files to *.o or *.s or *.S or *.i,
I would advocate to ask the ToolManager(ToolChain?, ToolFactory?,
BuildManager? ...) of the project on how to do this.  I do not see
the advantage of having this level of indirection.

For example changing 
/usr/local/g++-3/cstdio  ==> cstdio.i

So I would propose:
- you get some write access on org.eclipse.cdt.core
- put the interfaces to your proposal in the builder folder directory in cdt.core
- beat on the interfaces until we got something
- a default implementation for cdt.core.


>