I just caught up with this discussion after taking some time off for
packaging Corel's next opus. I agree with the idea that trival
piplineing a preprocessor into wrc will not leave enough information for
totally accurate error messages.
However: If the resource compiler understood the "#line <line #>
<filename> <visit #>" directives dumped inline by the preprocessor then
the line numbers would be accurate (or at least as accurate as gcc's :)
Intra line locations are always a problem however tightly you integrate
the preprocessor to the syntax checker/interpreter because the
preprocessor _changes_ the line (this is the whole point after all :)
and an arbitrary decision must be made which of the various generations
of the line should be displayed.
The source text is trivially available as source (given the line
number), and the compiler has the result of the preprocessing. The
nested macro substitutions are useless in a practical sense and hard to
store and retrieve anyway. Yes, code analysis tools sometimes do track
all of these intermediate calculations (usually not to the limits I have
implied) but we are not writing a code analysis too (yet).
I too say its past time to rip out the cpp stuff in wrc to make its
grammar smaller and much less complicated. However
#pragma/#line/#error support must be added as part of this.
<RANT>
At part of this work I suggest that we add --pedantic option to whine
when the resource compiler notices that it has C or C++ code in its
input. Declaring prototypes and structures without "#ifndef RC_INVOKED"
guard lines is sloppy coding and forces the tool to be kludged to
explicitly ignore such code. We had mondo trouble with C++ extensions
to the C grammar (and MS extensions to that) when we tried native
compilation and it could have been avoided with a bit of discipline.
</RANT>
Thank you :)
Albert.
Patrik Stridvall wrote:
>
> > > > Fortunately, standard cpp
> > > > seems to be enough, but if we were to require GNU cpp, what
> > > > would be the (real) problem???
> > >
> > > It is not a real problem but I prefer to minmize the depencies
> > > whenever possible. You have heard the story about
> > > "The straw that broke the {ass,donkey,mule}'s back", haven't you?
> >
> > OK, I did not say it explicitly, but the discussion was a matter of
> > principle only since standard cpp works. I agree with you
> > about unnecessary
> > deps. But to my mind, if a tools helps wine be better
> > (cleaner, faster,
> > etc), I opt to use it rather than complain about the
> > dependency. I was just
> > curios about your stand on this matter.
>
> Well, there is not only the matter of a dependency.
> Even though one important thing about Unix is
> "plumbing" a lot of simple tools, it is not always
> goods to do so.
>
> In this case with cpp and wrc, plumbing them together
> makes the error messages more cryptic which is not
> good.
>
> > > Anyway, I have do some experimentation and I found out that
> > > this simple patch implements a pre wrc call to the C preprocessor.
> > > Works with both Solaris C/CPP and GNU C/CPP.
> >
> > That's good news -- let's use that then and make wrc smaller,
> > and faster.
>
> I am not sure that stripping out the preprocessing code is a good idea.
> I see it more as temporary solution until wrc has implemented better
> preprocessor handling. As I said plumbing two tools together
> often gives more cryptic error messages. That is the reason
> why many C compilers and code analysis tools handles preprocessor
> directive by itself rather than using an external tool.
> IMHO wrc should do so as well.
>
> The patch is more a proof of concept, I am not suggesting
> that is should be applied, eventhough Alexandre is of course
> welcome to do so if he so whishes.
--
Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation
[EMAIL PROTECTED]
--
Corel has something new for you! Subscribe to our e-newsletter and
learn what's new and happening at Corel! Subscribe at
http://www.corel.com/newsletter
--
The address in the headers is not the poster's real email address. Do not send
private mail to the poster using your mailer's "reply" feature. CC's of mail
to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]".
The poster's email address is "[EMAIL PROTECTED]".
