> > Of course the list is changing, but so is
> > the rest of the compiler ;)
> > Documentation needs to be updated from time to
> > time.
> Apparently, this won't happen all the time. If there is a
> (semi)automatic way at least for some portion of it, why not grab on
Sure, if it's doable. I just have/had my doubts.
> > What is the use of a generated list? Is it to gain insight in what kind of
> > errors and warnings SDCC can produce? Anyone can see that in the source
> > code.
> It was created primarily as an aid for the disable_warning pragma. We
> are talking about _user_ manual of SDCC - I see no reason why should a
> user browse through the sources to get an information needed to use
> features of the compiler. Besides, the SDCCerror files are located in
> a rather unexpected corner of the sources pack... :-)
When the error/warning is issued it reports whether it
is an error or warning and its number. I don't see a
great need to suppress a warning one has never seen
And I too always wondered why SDCCerr.c/h are in such a
strange place. Maybe we should change that, since it is
possible with subversion.
> > Is it to more thoroughly explain the errors?
> It was not the primary purpose, but would be fine, certainly.
> > Then a generated list does not bring that info and it still must be
> added by hand. The generated list is probably a good starting point to
> be included in the documentation though. Then when new codes are
> added the documentation must be updated too.
> It would be relatively easy to add an another file, containing the
> list of explanations, and add it up to the list of errors and this all
> together add to the manual, in any form. If you supply me with the
> explanations (or at least some of them), I volunteer to make the tool
> as far as I am able to it (I can envisage a TeX format output included
> plainly into the lyx file, if lyx supports TeX inclusions).
I do not have better explanations ready, sorry.
> > Or is it only to make the severity level visible? For this automation
> > should be enough.
> That's of minor importance for the users and was included only as a
> PS Sorry I have access only to plain email at the moment so I cannot
> add this to the tracker...
All in all, I dislike generating yet another