Re: [cdt-dev] Scanner Discovery in 7.0

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

Thanks, Leo, as always :). comments below.

On Fri, Jul 23, 2010 at 12:41 PM, Treggiari, Leo
<leo.treggiari@xxxxxxxxx> wrote:
> Hi Doug,
>
>> I'm working on at a higher level in the architecture, making sure we
>> can break the build into three parts:
>
>> 1) build file generation (internal - i.e. managed build makefile
>> generator, or external - e.g. cmake, qmake)
>> 2) running the builder (internal - i.e. managed build internal
>> builder, or external - e.g. make, scons, jam)
>> 3) build output parsing when required (see below)
>
> I'd like to add a few other parts to the "builder" part of the architecture:
> 4)  The build environment
>    - part of this comes from the builder (e.g.) where the actual build utility is located
>    - part of this comes ideally from the tool-chain - or the user would have to provide
>      it if the tool-chain doesn't - if the user always uses the same tool-chain, their
>      build environment can be setup before running Eclipse
> 5)  Error parsers
>    - part of this comes from the builder
>    - part of this comes from the tool-chain - or the user would have to provide if the
>      tool-chain doesn't

That's probably true. One desire I have is to break out builder from
toolchain. They're currently tied together a bit unnaturally. For
example, I have the Android toolchain which if you follow the rules
uses it's own build system, ndk-build. However, there is work going on
to support CMake as an alternative build system. I can't really
specify that right now without setting it up manually.

> In any case, the core build model needs to control scanner discovery.  Right now the
> Builder and scanner discovery are "peers" without a well-defined interaction model.

It's not clear to me yet whether the build model needs to be in
control or whether scanner discovery uses the build model (to
determine the command). At the end of the day, it's all about
providing an IScannerInfo object to the parser, something that used to
be direct between the language model and scanner discovery, but now,
as you mention, is awkwardly managed using the project model.