[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] Build model proposal
|
You know, I've encountered the same issues when dealing with
flex/bison. Even in MSDEV, getting the rules set up so all
this works is a pain.
It would be really nice if the software supported the concept
of associating a chain of tools that need to be executed in a
certain sequence for building an object file from a source
file. In most situations, the build sequence would contain
one tool entry, but the architecture would support multiple
tool entries in the sequence to handle use cases like one
outlined by Martin.
If we get really motivated, the system could even emulate the
features in gnu make for dealing with intermediary and
secondary files.
gene
> -----Original Message-----
> From: Lescuyer, Martin [mailto:mlescuyer@xxxxxxxxxxxx]
> Sent: Wed 12/18/2002 1:02 PM
> To: 'cdt-dev@xxxxxxxxxxx'
> Cc:
> Subject: RE: [cdt-dev] Build model proposal
> Hi,
>
> > We can probably work with most of what you propose except the FMM,
> > if you need to transform a *.c or any other files to *.o or
> *.s or *.S or
> *.i,
> > I would advocate to ask the ToolManager(ToolChain?, ToolFactory?,
> > BuildManager? ...) of the project on how to do this. I do not see
> > the advantage of having this level of indirection.
> >
> > For example changing
> > /usr/local/g++-3/cstdio ==> cstdio.i
>
> This is very interesting. At Rational, some of the candidate
> tools to be
> plugged-in are using source code instrumentation (as many
> others I believe).
> This "custom build stage" must be called between the
> preprocessing and the
> compilation stages.
> Do you see a way of having this kind of service ? Instead of
> the extension
> point Sam proposed, based on the association of a file type
> with a tool, I'm
> thinking of the same extension point that would associate a
> translation with
> a tool or with a set of other translations. For example, the .c->.o
> translation would contain the compiler (or a reference to
> access it (an
> ITool?)), but this default content could be changed by
> program (and/or in
> the prefs ?), and would now contain .c->.i+.i->.ii+.ii->.o, where the
> translation .c->.i would contain the preprocessor, .i->.ii an
> instrumentor
> and .ii->.o the compiler (actually a copy of the .c.o
> previous content).
> Some people may also be interested in going though an
> assembly stage (.c->.o
> would contain .c->.s+.s->.o).
> This could also make easier the script generation (make is
> not very far..).
> Does this make sense ?
>
> Martin
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
>