Re: cpp seems not to include # line "file" output for empty files

[Daniel Berlin <dberlin at redhat dot com>]

"E. Jay Berkenbilt" <ejb@ql.org> writes:

> >   > >   If you want dependency info from cpp, use the switches to tell it to
> >   > >   give you dependency info.
> >   > 
> >   > Not portable.
> >
> >   Oh, but expecting a certain format of preprocessor line info is.
> 
> Point taken.  However, I've used the technique of looking at the line
> output on preprocessors on about a dozen platforms over about 8 years
> and it's worked on every single one including all previous versions of
> gcc.
> 

Really?
That's actually pretty surprising.
I've always just used 2 regexes to scan for #include's, and generate
the tree that way.
Is there a particular reason this isn't a good solution that i should
be aware of?

> >   > >   Also, if the file generates no output, then a.c really wasn't dependent
> >   > >   on it.
> >   > 
> >   > Wrong -- see my example.  a.c is most definitely dependent upon a.h.
> >   Um, no.
> >   If it's not using any of a.h, it's not dependent on it, or else it's
> >   output would be necessary.
> >   You are using a definition of dependent that happens to fit your task,
> >   which happens to not be the general definition of dependent.
> >
> >   You could remove the line including a.h, as it stands now, and a.c
> >   would not be affected.
> >   Therefore, a.c is not directly dependending on a.h
> >   --Dan
> 
> This is nitpicking now.

Not really, it's hard to reproduce a bug without a testcase pointing
it out.

Your testcase isn't really exposing the bug, so it can't really be
used to track it down.
>   The point is that a.c includes a.h.  If a.h
> changes, a.c should recompile.  If I changed my example so that a.c
> used a.h so that you would agree that it is dependent, would you agree
> that there is a bug? 

I already agree there is a bug, I don't agree that the testcase
demonstrates it.

> 
> I don't want this to take a negative tone -- my intention is to report
> what I perceive to a bug in hopes that it can be fixed.
> 
> If you are telling me that you are a gcc developer who has the
> authority to decide what is a bug and what isn't a bug, and that you
> believe that this isn't a bug, I will accept this verdict and add
> special case code to my dependency generator to handle gcc differently
> even though it works fine on compilers from Sun, HP, SGI, and even
> proprietary compilers for embedded systems and Windows.  It will only
> require a few lines of code, so it's not a problem, even though it's
> annoying.

Whoa there, come down.
It's irrelevant if i was a gcc developer with the "authority to say
what is a bug and what isn't". You are reporting a bug against a
version of gcc distributed with redhat that isn't simply a cvs
snapshot, but a cvs snapshot+ a lot of patches.
The current cvs gcc has no such problem.
So if you want the bug fixed, report it on bugzilla.redhat.com, not
here.

> 
> I don't want to argue over semantics of what dependent means.  My bug
> report is that, although a.c includes a.h, a.h is not mentioned
> anywhere in the cpp output contrary to past behavior of gcc and
> "usual" even if unreliable behavior.
> 
> Thanks for your responses.
> 
> If you are just someone who subscribes to this list and the decision
> about whether this is a bug rests with someone else, then I will
> respectfully make this my last word on the subject until I hear from
> someone who will either say, "This is not a bug and we won't fix it"
> or "This is a bug and is on the list of things to be fixed."

That won't happen either way here, nobody on gcc-bugs enters bug
reports into bugzilla.redhat.com

> 
> --
> E. Jay Berkenbilt (ejb@ql.org)  |  http://www.ql.org/q/