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