Re: -MM, 2.95 vs 3.0

[Ian Britten <britten at caris dot com>]

On Tue, 19 Feb 2002 21:53:45 +0000
Nathan Sidwell <nathan@codesourcery.com> wrote:

> Ian Britten wrote:
> I think you're using the wrong tool to solve the problem.

... (sigh)   Wouldn't be the first time...  :-/
[ "When all you have is a hammer, every problem looks like a nail" ]

> It might help to think about 'library' header files, as opposed to 'user'
> or 'system' header files.
> 
> system header files are those which support the compilation environment, or
> support the o/s (have intimate knowledge of the hardware).  These generally
> contain some chicanery which, in user code, would elicit a warning.
> 
> library header files are those which support some random library of
> utilities. system headers are a subclass of library headers
> 
> user header files are those which you are developing.

Ya, that's clearer.  I had always been thinking of it as 'my' header files,
or 'everyone elses' header files.  Adding a third group makes it more
clear...

> The behaviour that I understand that you want (and I can see the logic of),
> is that once a dependancy reaches a library header file, the chain should
> stop.

Er, well... that was what we had been _using_ (based on the behaviour of GCC).
Now, whether that is what we _want_.... (More below...)

  [ snip ]
> No. the difference between <> and "" is *only* that "" first looks relative to
> the directory containing the including file, before using the include search path.
> Both <> and "" start at the begining of the include search path. You should
> use "" if you want to locate the included file relative to the including file.
> If the included file could be anywhere, use <>.
  [ snip ]
> For instance, 
  [ snip ]
> Your library is guaranteed to #include the files you expect it to include, regardless
> of whether the user has managed to put a different 'mylibconfig.h' or 'mylibsubsystem/subsystem.h' reachable by the include search path.

I think we knew that...
However, I think we became addicted(?), focused(?) on GCC's behaviour, and
this became the driving concern...

> What you really want is a way of indicating that a header is a 'library'
> header, rather than a 'user' header. The system header file distinction
> is inadequate.
> 
> What about
> 	#pragma GCC library_header
> ? Its presence would cause the dependency graph to be terminated at this
> header file. So that you could generate dependencies when developing the
> library, you'd use something like
> 	#if !BUILDING_MYLIB_
> 	#pragma GCC library_header
> 	#endif
> (Neil, do you think something like this would fly? It strikes me as a more
> meaningful distinction for dependencies.)

No comment from me.  I think my solution is below...

> > 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.
> why are you not regenerating the dependancy graph for different compilers
> & OSs?

I think this is the crux of the problem (and perhaps where my solution lies)
Years ago, we came to the realization that:
- Our code is always changing
- 3rd party stuff rarely changes
- GCC could generate dependencies for _just_ our stuff (through a specific
  combination of #include "" and -MM options...)

Thus, we devised our build system such that there was one common directory
where all the platforms shared the dependencies (for the current
library/executable), and all the builds for all the platforms used/updated
them as needed  (After all, it was just *our* headers! :-)
   ie
       .../lib1/                   <- Source code
             linux-gnu/            <- Linux optimized object files
             linux-gnuD/           <- Linux debug optimized files
             sol-CC/               <- Solaris optimized object files
             sol-CCD/              <- Solaris debug object files
             ... <others>
             depend/               <- Dependencies, shared for all builds

I guess it's time to re-examine this assumption, and perhaps to generate
the dependencies per-compiler/platform (especially if GCC is going to
change...)

Thanks for all your input!
Ian

[ FYI - Reminder... 
  Note that GCC v3.0.1 does _not_ behave as you/Neil describe (ie. that the
  dependencies are for all non-SYSTEM files), but is still as I described
  (Only files included via "").  Newer versions may work the way you
  describe (Haven't tried yet), but if you think 3.0.1 behaves the way you
  describe, there may be a bug in it... ]