This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

-MM, 2.95 vs 3.0

Hi all,
[ This originally started in, but after some private email,
Neil Booth (CPP co-maintainer) suggested I bring it here directly.  Sorry
for the length, but I'll try to completely summarize/recap everything... ]

My original inquiry started as:
----------------------- From ---------------------------
Can someone confirm an intended behaviour change between 2.95 and 3.0.1
regarding dependency generation (-MM option).

I have a file (a.cpp) that includes its own header file (a.h)
         #include "a.h"     // <- Note the use of quotes

a.h includes some other (3rd-party) header files
         #include <b.h>    // <- Note the use of brackets

Unfortunately, b.h includes some other stuff, and I can't change it
         #include "blah.h"    // <- Note the use of quotes

When generating dependencies for a.cpp (via the -MM option) with
2.95, a.cpp would only be dependent on a.h, which is what I want.

However, with 3.0.1, it appears that processing continues _through_
b.h looking for any/all files included with "".  As a result, a.cpp
now has a dependency listed for blah.h, which it didn't used to.
This causes endless grief when working on multiple platforms, where
"blah.h" is installed in different absolute paths.
----------------------- From ---------------------------

With v2.95, the dependencies seemed to be determined by the quoting style
of the #includes.  However, Neil indicates that with v3.0, it has nothing
to to with quoting style, but instead, uses knowledge of what are 'system'
headers versus non-system headers (I hope I got that correct).

Where we run into a problem is when working with 3rd-party (but non-system)
header files (Stuff like GTK, PNG, ICU, etc).  By #including the 3rd party
header files with <>, that acted like a stopping condition, meaning that we
would have no dependencies on anything it subsequently included.  This was
nice, as it could be controlled by the code *user*, and didn't matter
whether the code *author* got the correct(?) #include syntax or not.
If we _wanted_ to be dependent on them, we could simply #include them
with "".

This becomes more obvious/useful when working with one set of code (and 
one set of dependencies), on multiple compiler/OSs, where the same 3rd
party stuff may be installed in different directories.

I'm not really sure if this behaviour was intended, or correct, but it
was certainly useful... ;-)   

So, to sortof summarize:
With 2.95, I (as a developer) could say that 
  "This code is being developed/changed a lot, so I want to be explicitely
  depenendent on it"
and I would do so by #including the code with "" (which is what we do for
our own files).
However, I could also say that
  "This code is a 'real' system file (string.h), or a stagnant 3rd party
  file that rarely changes, and I choose to not be explicitely dependent
  on it"
and I would do so by #including the code with <>.

This evolved from the description of how the dependency generation of
GCC behaved, specifically the -MM option, in conjunction with the quoting

[ Something else:
  In-house, when we're developing our libraries/applications, the developers
  obviously want to be dependent on our own work.  So, we #include our own
  stuff with "", even from within our own header files.  However, once our
  headers/libraries go to a customers site, we *become* the 3rd-party
  software (to them).  We don't post-process our #includes, but our
  customers  probably(?) don't want direct dependencies on our software (as
  our code wouldn't change much as far as they are concerned)
  Should we be changing all our "" to <> for them...?

Anyways, maybe we've been doing it wrong all this time, and someone here
can point out a better way.  Or maybe the old behaviour could be maintained
or added back in sometime?

Thoughts?  Suggestions?  Thanks for any info!
Ian  (Please CC to, if possible...)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]