Re: fixincl on linux systems

["Andi Kleen" <ak at suse dot de>]

On Mon, Sep 25, 2000 at 10:25:32AM -0700, Bruce Korb wrote:
> > A lot of rpms put include files into /usr/include which sometimes fixincl
> > likes to fix up (mostly for relatively silly things like // -> /* */ comments
> > that do not affect usability with gcc -- include files on linux systems
> > tend to work with gcc)
> 
> Many months ago that was fixed by allowing // comments in system
> headers.
> fixincl no longer makes that change.  I will send you under separate
> cover
> a tarball of the current gcc/fixinc directory.  It ought to be a drop-in
> replacement for whatever you are working with.  Let me know what your
> resulting
> issues are.

It still seems to process a good number of files on a stock SuSE install
(I have not checked recently what it changes exactly, some time ago it 
were the // comments) 


> 
> Here is one I have:  OpenServer 5 comes with an include subdirectory:
> 
>    /usr/include/oldstyle
> 
> wherein the K&R style of headers reside.  Needless to say, a lot of
> the headers are fixed.  But it is pointless to do so.  They are never
> (or should never be) seen by the ANSI/ISO/C9x flavor of C compiler.
> Therefore, it would be good to omit them from fixinc processing.
> I propose an addition to the platform specific headers that, when
> defined, provides a file name pattern for fixincl to ignore.  For
> OSr5, that would be "oldstyle/.*".  For Linux, alas, that would *not*
> be ".*".  At least, not unconditionally.  It would have to depend
> upon the version of libc because it, occasionally, has bugs, too.

For Linux it would be better if it was a white-list, not a black list.
It is near impossible to collect all the names of obscure includes from
various rpms.
rpm unfortunately made it common to install lots of third party include
files into /usr/include, so a simple directory pattern would not help.

> 
> Perhaps along the lines of:
> 
>   #if libc-is-newer-than-some-threshhold
>   #  define  FIXINC_BYPASS_PATTERN  ".*"
>   #endif
> 
> > I end up with lots of private copies of include files in the gcc directory
> > after a build. When the rpm is updated later the private copy isn't.
> 
> That would be solvable if fix-headers and fixincl were a single,
> separable
> process.  You cannot just install "fixincl" and rerun it because of what
> fix-headers does later  :-(.

It would break anyways with multiple gcc versions installed. I tend to
not replace the system compiler with a gcc 2.96 test, but install it into
some private directory and call it explicitely. 

> 
> > Now when the interface of a library in the rpm changed accessing it with older
> > include files usually leads to miscompiled programs.
> > 
> > My current solution is to simply rm -rf the files after install, but not
> > generating them in the first time would be better and faster.
> > 
> > I would appreciate it if you could consider a --disable-fixincl switch.
> 
> I hate command line switches that are always used in one context
> and never used in another.  Better to have the context be queried about
> or provide the information, as I have suggested above.

I'm not sure I follow. There are certainly lots of contexts where a user
can say that he doesn't care about all of /usr/include. 

Context querying is usually fragile, and it would make
sense to allow the user to override it when he knows what he is doing
(similar to e.g. he can say --disable-nls) 


-Andi