[
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