RE: [cdt-dev] Scanner Discovery in 7.0

["Treggiari, Leo" <leo.treggiari@xxxxxxxxx>]

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

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.

Thanks,
Leo

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Friday, July 23, 2010 7:56 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Scanner Discovery in 7.0

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)

Scanner discovery itself has two parts:

1) build output parsing as I mentioned above which extracts compile
commands from the build output
2) scanner info provider which determines what the scanner info for a
given file based on the compile command used to build that file. That
command can come from the data collected by the build output parser,
or from managed build data, or elsewhere.

I have no pre-conception on how that plugs into the project model and
maybe that's where your design comes in. But as long as integrators
can extend build output parsing to cover the syntax of their compiler
options, and separately extend the scanner info provider to do the
translation from command line to scanner info, I'm happy.

At any rate, this is definitely on the agenda for the summit.

On Fri, Jul 23, 2010 at 9:47 AM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
> Currently it is still the old one although we fixed a few bugs. I am working
> on a new one along the lines of the proposed design. See also bug 290631. I
> am still seeking feedback of which I got very little. Thanks to those who
> responded.
> After 7.0 I moved that development to git repository. I am working on it
> steady but slow as I don't have much time these days.
>
>
> Andrew
>
>
>
> On Fri, Jul 23, 2010 at 8:06 AM, Sebastian Huber
> <sebastian.huber@xxxxxxxxxxxxxxxxxx> wrote:
>>
>> Hi,
>>
>> I try to adopt my CDT extension to 7.0.  Do we have a new interface to the
>> scanner discovery in 7.0 or is it sill the old one.  From what we have
>> here
>>
>> http://wiki.eclipse.org/CDT/ScannerDiscovery61
>>
>> it is not clear how the current status looks like.
>>
>> Have a nice day!
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>> Phone   : +49 89 18 90 80 79-6
>> Fax     : +49 89 18 90 80 79-9
>> E-Mail  : sebastian.huber@xxxxxxxxxxxxxxxxxx
>> PGP     : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev