How far to fix includes?

[Bruce Korb <bkorb at sco dot COM>]

Richard Henderson wrote:
> On Mon, Dec 04, 2000 at 12:43:46PM -0800, Geoff Keating wrote:
> > But that's even worse!  It means that now every time ncurses (or bfd,
> > or e2fstools, or gtk, or python, or whatever) is upgraded it might be
> > necessary to ship a new gcc package!
> 
> So what?  This is not the FSF GCC team's problem.
...
> The only possible solution to your concern is for the system distributors
> to examine fixincludes output, locally adjust each package, and then
> locally change the gcc package not to run fixincludes.  We might perhaps
> consider adding a configure option to make this easier, but that is as
> fas as I'd be willing to go.

What if we made the fixincl program installable?
Then, if the compiler were to take issue with content of a
header, the installed version could be given the name
of the out-of-date header and process it into the hidden
directory.  Perforce, the installed include fixer would 
be a different binary than the one run during the build.
It would have to know information from the "make install"
step and it would have to be run with sufficient privilege.
In this scenario, if a package were to be updated that
exported fixable headers, you would later run this script:

  cd /usr/include
  sh ${gcc_installed_version_path}/fixincludes

and everything that needs to happen just happens.