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

[E. Jay Berkenbilt]

>   > >   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.

>   > >   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.  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 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.

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."

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