[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Communication with the compiler
|
IMO, people who don't use Make should get the same support as today. Improving
support for Make should be good, destroying support for other tools would be bad.
Your "command" thingy sounds like a good idea to me.
Just trying to figure out whether nagging the GNU Make people for features would
be worth it (it won't be if nobody is interested in implementing the
corresponding support for the CDT).
Cheers //Johan
Thomas Fletcher wrote:
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
