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

["Alain Magloire" <alain@xxxxxxx>]

> 
> Ugh! Too true about the cobbled-together build environments. To add to the
> list, there's a lot of GNU projects using automake/autoconf tools as well. I
> go back to a key requirement for the parser (which in turn provides the
> information we need for indexing, searching, code assist, refactoring, etc)
> which is knowing the includes paths and defines for a particular project
> configuration. To get this from existing projects, we were thinking that
> there are two options for such users. The first is to remain an "unmanaged"
> system. Under that scenario, users would have to enter environment
> information, include paths, and build macros manually. They would also have
> to maintain them in the event that they changed. Is that a pain-point? You
> bet! However, it represents the lowest level of information we can get away
> with storing and still offer those additional features. 
> 
> The other option for existing customers is for us to take over managing the
> makefiles/build. This would likely involve a one-time, best effort parse of
> the makefile system to determine this information automagically, but as you
> point out, any number of (sadly typical) roll-your-own build environments
> can and will trip us up. In this case, there is a pain point for the user
> but if it happens only once, maybe this barrier is low enough. I doubt it,
> but it's the best we can do.
> 
>
> A lot of this ties into your points about integration below.
> 

300% behind you, in my experience customers/users will also understand
this and overtime some of them will migrate to the more feature full environment
(the default builder of the IDE) or make custom adapters to be able to fully
participate in the IDE, the integration points.

To take you examle about the ... GNUDE 8-)
I want to make a GNU adapter/builder for the CDT, because I have good
understanding of layout of the Makefiles, the configuration files
(configure.ac, Makefile.am, Makefile.in, ...) and the tools
(autoconf, automake, etc ..), I can probably do
a much better job then the default Makefile parser to get/set information. 

This is also a good example of a third party integration.

> > There are many levels of integration:
> > - (High) Take over the entire implementation: On some 
> > environment because
> >   of the complexity, it will be simpler.
> >   For example, the QNX builder is extremely smart/mature and 
> > yes we could
> >   completely implement the build model, for now we take over 
> > the builder
> >   at the Eclipse/platform level, but by doing this, other 
> > components can
> >   not access the information. (Note: this is an example, we 
> > do not know
> >   yet how we will integrate our builder in the CDT Build Model).
> > 
> > - (Medium) Extending at some key points:  For example, if the 
> > information is kept
> >   in a database somewhere and all is needed is to implement 
> > is say the IToolChain
> >   or maybe the ICBuilder etc ..
> > 
> > - (Low) Lowest level: just the parser for the a tool, for example the
> >   compiler is microsoft or Watcomm compiler with  a different 
> > error patterns
> >   but the default scheme is fine.
> > 
> > 
> I want to make sure we are talking about the same thing. You have stated
> that you think the build model should be completely replaceable so you can
> use your QNX builder. The thing is, the build model is a repository for
> information (at least in my mind) and the builder is the client. The
> extension point for the ISV to insert the information about their own tools
> is the toolchain (and maybe to replace the builder). I guess you would like
> to be able to use your QNX builder both as the build model AND the builder.
> If we come up with a decent interface, could you not extend your builder to
> realize it, so the parser (and any other client) can extract the info they
> need directly from you?
> 

This is the point of contention 8-).  To be able to answer, we need a better
understanding of the CDT Build Model.
The QNX builder is smart, it knows about how the project is layed out,
the type of the project(DLL, library, profiling, etc ..), the macros,
the compiler options, the library needed, the project dependencies, etc ......
But some information can only be known at runtime(for example by doing a dry-run).

So how/where can we third parties integrate cleanly with the CDT Model ...
I do not know 8-)  This is something we'll have to find out.
 
> My other primary goal with the build model and builder is to make the CDT
> useful out-of-the-box to as wide a range of developers as possible. Other
> vendors can decide the level of integration they want to support. I guess
> the challenge for us to to make the extension points and build model
> interfaces to the toolchain and build model clients sufficiently general.
>  

Of course! that goes without saying, it is a key-point of any respectable IDE.
We should work to make the default builder, as complete/smart as possible.



The other question on this, can you set multipe builders within the CDT builder ?