Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


Back to the top