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

["Alain Magloire" <alain@xxxxxxx>]

> 
> Just to toss in some of our thinking on the subject.
> 

Some good points, comments below.

> Builders
> I have to agree with Sam on this point that we should stay as flexible as
> possible by dividing up the responsibility for maintaining information and
> doing something with it. The build model "knows" about build order
> dependencies between resources in the configuration, keeps track of build
> flags/environment/macros/etc, knows about any special build steps the user
> has specified, and knows what toolchain is associated with the project. 
> 
> The toolchain understands the mapping between resource elements and what
> tools get invoked to build them. The build model asks the toolchain how to
> perform the build steps and how to construct the final build artifact. 
> 
> The builder is the front end for making all this happen. It relies on the
> information in the build model. We could probably expose this through a
> default builder and allow other people to specialize builders to do
> different thing. For example, we could construct a builder that generates
> makefiles to create the project or a builder that does everything
> internally. In both cases, the builder is determining what to do by querying
> the build model about what to build and how.
> 

Yes, agreed.
I want to point a difficulty: not all framework enviroment can be coerce
to do this that easily.  For example, an environment that uses recursive makefiles
to get the information, on how to build a specific resource, you pretty much
have to walk up the entire Makefile structures(reimplementing GNU make) to
get to the right rule.  Sometimes, the info can be fecth by a dry-run
or a "make -p" as you pointed below.

# make --dry-run foo.o
gcc -D_MIPS_ -c src/foo_stub -o foo.o

Some enviroment builds are a mixed of shell scripts, some other build frameworks
ride on top of databases, etc ..
I've seen customers drop excellent IDEs because it was not possible to
use them in there framework and would like to see flexibility in the CDT.


> Existing Projects
> Gotta be able to support this large group and the current builder is
> sufficient for them. We could add some value by creating a nice makefile
> editor and/or supporting an "outline" view for the makefile. Minimally, we
> would want to allow a user to manually enter compiler defines and include
> path information in the configuration, even if they did not use a
> fancy-pants builder. This information would make our parsing more accurate,
> thus enabling better searching and refactoring. We might even want to
> "parse" the makefile for them by calling 'make -p' and pulling out relevant
> information (yuck!). Granted, these values are relatively static, but this
> could be a pain-point if a user had to do this on an ongoing basis. Given
> that, we have also discussed whether we could migrate an exisiting project
> to a "managed" makefile. If we did allow CDT to take over managing the
> makefile, we thought it would be a one-way migration (i.e. it implied the
> user wanted CDT to generate the makefile for them).
> 

8-) 100% in agreement.
As long as there is a way for people not starting from scratch i.e.
We can find some compromises and still make the IDE usefull for this cases.

> Replacing Entire Model
> I can see how an ISV might need to extend the model somehow to support their
> own special environment, so perhaps we could use the extension point concept
> here. The problem is that there will be a dependency between the builders
> and the build model, as well as the parser and the build model (includes
> path info springs immediately to mind). If we really believe that people
> would completely reimplement the build model, then we could make the build
> model an interface and supply one possible implementation. The interface is
> probably a good idea anyway, from a design perspective.
> 

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.


> Error Parsers
> In my initial design work, I thought that error parsers could be attached to
> the specific tools in the toolchain. So, a toolchain supplier would not only
> return a wrapper to invoke a particular tool, they would also attach an
> error parser that would return correctly formatted errors for the task list.
> Of course, this gets dicey when you throw a generated makefile builder into
> the mix, since make returns errors that are a far less detailed. We will
> have to think a bit more on the subject.


How the code is now for the Default builder (ACBuilder, CBuilder).
There is an ErrorParserManager attach to the builder, and a chance to
add has many IErrorParser classes as needed, the default now is

ErrorParserManager.addParser(GCCErrorParser); 
ErrorParserManager.addParser(GLDErrorParser); 
ErrorParserManager.addParser(GASErrorParser); 
ErrorParserManager.addParser(MakeErrorParser); 

The builder/ErrorParserManager gives a chance to all the IErrorParser[]
to have a look out the output and do some matching.  If a pattern
match the IErrorParser set a ProblemMarker.

There was, however, no UI component to this, and the idea was to let
user or ISV add/remove IErrorParser to a builder/ErrorParserManager via
a Preference page or extension points.

The other problems were doing a "make clean" and the passing of specific
targets.  Some targets like "clean" are special, since the entire
build state as to be flushed.