This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: MI error msgs and localization
- From: "Bjarke Viksoe" <bviksoe at hotmail dot com>
- To: gdb at sourceware dot org
- Date: Tue, 14 Feb 2006 18:40:24 +0100
- Subject: RE: MI error msgs and localization
- Bcc:
> the front-end as a "dumb automated shell" and into thinking "integrated
> environment with user friendly error messages". Preferrably these
messages
> should have been streamed out as a MI result-records.
I would guess that most of time GDB is used from the command line where
there
is simply no front-end, dumb or otherwise.
But we are talking about MI mode now and how that should be shaped?
The error message "Unrecognized option" is not intended to provide
information
about the GDB version. If you want to use it for that purpose, thats your
choice, but you can hardly expect the GDB community to "support" that
feature.
I don't get your point. A front-end can decide how it wants to interpret an
error message as it pleases. I do it because this is the error I get when
-i=mi is used on a version that does not support it at all. It makes sense
in that context since I'm building the command line.
I don't particular like to hard-code these strings. The list of messages I
gave previously are all marked as console-stream-output. What I am saying is
that localizing such error messages will hurt MI dependant tools since the
messages are highly useful for the front-end. I'm not sure what purpose
console-output really has in a Machine Interface as it tends to make sense
only to humans - but I guess some systems are making use of them.
What I'd really like is to see them also wrapped in result-records (sample;
ignore syntax):
^failed,type="init-option-unrecognized",msg="Unrecognized option"
Does that make any sense?
My initial warning was that without "cleaning" the code and making sure
*all* spurious messages are classified and wrapped in proper MI records,
localizing may break some tools or see important features disappear because
they were using the raw console output in lack of proper MI structure
wrapping.
regards, bjarke viksoe
80386.NET - http://www.viksoe.dk/code/asmil.htm