Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Scanner Discovery in 7.0

Hi Doug,

> 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.

I agree that the builder and toolchain should be more independent than they are today.
As a toolchain provider, I'd like to be able to work with as many builders as
possible, even ones I didn't know my users would want to use.  But there are places
where both the builder and the toolchain need to be able to provide information
and the build model (probably) has to be able to combine the information for the
build - and to provide the scanner info to the language model.

Examples include:
-  Error parsers - the tools in the toolchain will issue errors and the builder 
   will issue errors
-  Scanner info - some builders (e.g. managed build) can provide much, maybe all, of the scanner information without a build output parser
-  The Build Environment - the build needs to find the builder and the tools

Speaking of the language model, it is really the tool-chain that knows what
language is being used (currently some variant of C/C++/Fortran).  The tool-chain
should be able to specify the default parser.

The overall C/C++ IDE model is really quite complicated.  It might help if we had
a high level design of:
-  What all of the objects are
-  Which object is the sole provider of what information to the rest of the model
-  Which objects need to be able to contribute information to the provider
-  ...

I guess the overall model is the CElement stuff, but I don't think it is complete.

Thanks,
Leo

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

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.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top