RE: [cdt-dev] Build model proposal

["Sally, Gene" <Gene.Sally@xxxxxxxxxxx>]

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