RE: [cdt-dev] Communication with the compiler

[Thomas Fletcher <ThomasF@xxxxxxx>]

What about people who use JAM? People who don't use GNU make? People who
use shell scripts of one flavour or another?

To me this really isn't a very generic solution ... although this might
be a specific implementation of a generic framework (ie one in which
there are multiple error parsers tied to "commands" and in this case you can
use the number mapping to determine which "commands" are being invoked
and lookup the appropriate parser).

Just my random morning thoughts,
 Thomas

> -----Original Message-----
> From: Johan Walles [mailto:d92-jwa@xxxxxxxxxxx]
> Sent: June 30, 2003 4:29 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] Communication with the compiler
> 
> 
> I would guess that getting a machine interface into both GNU 
> Make and gcc should 
> be doable.  WRT GNU Make it should be simple:
> 
> 1. Enumerate all external programs called.
> 2. Before each call to an external program, output the exact 
> command line 
> (preferrably with full path to the executable) that will be invoked.
> 3. Prefix the command line and all its output with a unique number.
> 4. After a command completes, output some end marker.
> 
> So, the output from calling a makefile that calls "echo foo" 
> and nothing else 
> could look something like:
> 
> 1: /usr/bin/echo foo
> 1: foo
> 1:Exitcode 0
> 
> This would make it possible for CDT to see what compiler (and 
> version) the 
> Makefile actually calls.  Also, it would make it possible to 
> parse the output 
> from parallel builds.  If we have a parallel build that calls 
> "echo foo" and 
> "echo bar" in parallel, that should give you:
> 
> 1: /usr/bin/echo foo
> 2: /usr/bin/echo bar
> 1: foo
> 2: bar
> 1:Exitcode 0
> 2:Exitcode 0
> 
> I can see how the gcc part would be more of a problem, but 
> talking nicely to 
> Make seems to me as a good start.
> 
> If something like this was implemented in GNU Make, would you 
> consider utilizing 
> it when parsing its output?  If so, I could file a feature 
> request with GNU Make 
> once we have agreed on a suitable protocol.
> 
>    Cheers //Johan
> 
> Douglas Schaefer wrote:
> > Definitely an interesting idea.  I'm not sure whether we 
> can bank on 
> > compiler developers doing this for us, though.
> > 
> > In the short term, i.e. CDT 1.2, we will need to put in an 
> extension point 
> > for error parsers so that it is much easier to add new ones in, and 
> > localized compilers is a great example of that.
> > 
> > In the long term, I would like to see an internal build system that 
> > invokes build commands directly, instead of just calling make.  The 
> > problem with invoking make is that we have no idea which 
> tool is actually 
> > sending back the messages (well we can make intelligent 
> guesses, but...). 
> > With an makeless build, handling of feedback from the build 
> tools can be 
> > more robust and customizable, including any out-of-band 
> communication 
> > channel they may provide.
> > 
> > Thanks,
> > Doug
> > 
> > 
> > 
> > 
> > Johan Walles <d92-jwa@xxxxxxxxxxx> 
> > Sent by: cdt-dev-admin@xxxxxxxxxxx
> > 06/27/2003 06:25 AM
> > Please respond to
> > cdt-dev@xxxxxxxxxxx
> > 
> > 
> > To
> > cdt-dev@xxxxxxxxxxx
> > cc
> > 
> > Subject
> > [cdt-dev] Communication with the compiler
> > 
> > 
> > 
> > 
> > 
> > 
> > Currently, the CDT parses the human-readable output from 
> the compiler and 
> > creates tasks out of those.  There are a couple of problems 
> with this 
> > approach:
> > 
> > 1. If the compiler output is localized (like in newer 
> gcc:s), the error / 
> > warning classifications (and possibly other parts of the 
> message parsing) 
> > will 
> > break.
> > 
> > 2. If some sort of "quick fix" machinery is ever to be 
> implemented for the 
> > CDT, 
> > the CDT needs to understand what the compiler is 
> complaining about.  If 
> > the 
> > compiler's error / warning messages get modified / localized, that 
> > understanding 
> > will break.
> > 
> > In the long term, I think this will have to be dealt with 
> in some way. One 
> > way 
> > may be to ask the compiler developers for some kind of 
> "machine interface" 
> > 
> > similar to what gdb provides currently.
> > 
> > Any other ideas?
> > 
> > I'm trying to bring this up early enough that if some sort 
> of support from 
> > the 
> > compiler developers is deemed to be helpful, they will have 
> some time to 
> > do 
> > something about that.
> > 
> >    Cheers //Johan
> > 
> > _______________________________________________
> > 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
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>