Re: [cdt-dev] Internal builder status

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

While the implementation has gone on quite a journey and is pretty
confusing, I believe it still embraces the vision we had for the build
system.

And, as James mentioned, we essentially have three steps to the CDT build.
1) Build file generation - currently done only if project is "managed"
2) The build proper - runs the external build command or the internal
builder (of course the internal builder only works with managed
projects)
3) Scanner Discovery - parses build output to gather info for CDT's parsers

Scanner discovery is a bit of a mess as it does pre-date the project
model work that brought configurations into the core and isn't well
integrated with that. Also, it does two jobs, 1) figuring out compiler
command-line options from the build and 2) tries to figure out
built-in options for the compiler and for some compilers, e.g. gcc -m
options, these are related as you may need to know the command-line
options to figure out the built-ins.

What I would like to see is the build file generation step made more
generic and allow it to run external build file generators, such as
configure, CMake, qmake, just as we have an internal builder and an
external builder. Our support for external build file generation has
been very weak as Jeff from Red Hat can attest to with his configure
work. The Qt work as a second example should bring us to take a better
look at that.

Doug.

On Tue, Jul 13, 2010 at 10:27 AM, James Blackburn
<jamesblackburn@xxxxxxxxx> wrote:
> Hi Warren,
>
> On 13 July 2010 14:16,  <Warren.Paul@xxxxxxxxx> wrote:
>> A few years ago there was standard make, which simply called make on an existing makefile, and managed make, which created and maintained makefiles.  Managed make introduced the build configuration concept, which I believe was then added to standard make as well.
>
> Configurations are a core concept. So all the language settings
> interesting to the parser / indexer (mostly includes & defines) are
> persisted / managed per configuration. One major sore point is scanner
> discovery which lives in a pre-configuration world...
>
>> I see now there's this concept of managed make with internal or external builder.  Is the former just managed make, and the latter standard make, or is there is still an actual standard make builder?  If so, what's the difference between the two?
>
> The build hangs off CommonBuilder which is in need of a spring clean.
> Running a 'standard build', if we were to ignore the subtleties of
> error parsers, scanner discovery, etc.,  just requires firing of an
> external process -- often 'make'.  As there's nothing special for the
> build system to do, this job is just incorporated by CommonBuilder.
> So Standard/Makefile build is the same as 'managed' build except the
> user (or project template) has "Generate Makefiles Automatically"
> unchecked in Properties > C/C++ Build
>
> For managedbuild there are two modes of operation: makefile generation
> + run external builder and the internal builder.  When automatically
> generate makefiles is enabled (and external builder chosen), the
> makefile generation step is run before make.  The build has the same
> shape as standard build - except for the initial makefile generation
> step.
>
>> How is the indexer hooked up in these projects?  I created a Qt project and the indexer just seemed to work, but I wasn't sure how.  :)  Is it getting the macros and include paths from the makefile?  I didn't see any place to specify the makefile location, so I was a bit puzzled as to how it was working.
>
> The paths and symbols come both from the build system and from scanner
> discovery (which provides builtins + make output parsed -Ds + -Is).
>
> Cheers,
> James
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>