Re: kern/46557: sys/syslog.h can't be compiled on its own with -D_KERNEL

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/46557; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/46557: sys/syslog.h can't be compiled on its own with
 -D_KERNEL
Date: Sun, 11 Oct 2015 01:21:32 +0000

 On Thu, Sep 10, 2015 at 12:00:01AM +0000, Richard Hansen wrote:
  >  > it has to wait until we've migrated to a source control system that
  >  > tracks file renames.  And that remains problematic.
  >  
  >  :(  The lack of an official Git repository is one of the reasons why I
  >  haven't contributed as much as I could have.
 
 Git doesn't track renames well enough. :-|
 
 (among other issues)
 
  >  > I don't think that such undertaking is worth-while
  >  
  >  This undertaking would be a huge time sink with no short-term gain, but
  >  there is long-term value:  You'd have code that is more
  >  readable/understandable by potential new contributors.
 
 Right.
 
  >  > since none of the kernel headers are documented to be standalone.
  >  
  >  Nowadays the expectation in the broader C community is that headers are
  >  standalone.  Headers that aren't standalone need to be documented as
  >  such, not the other way around.
 
 Right.
 
  >  > Also if you do that you should clean the userland visible
  >  > headers to avoid duplicate inclusions for efficiency.
  >  
  >  Would the performance hit be noticeable?  I suspect the overhead of
  >  processing include guards and skipping lines of input code is orders of
  >  magnitude less than the work of compiling the resulting preprocessed code.
 
 Remember NetBSD still supports a wide variety of junkyard hardware :-)
 however, all this is implicit in the big header cleanup anyway.
 
  >  > It is not like if you fix it once, it will stay fixed since there is
  >  > no harness to check that each header is compilable standalone (but
  >  > you will need to write one too).
  >  
  >  For this reason I have the following personal policy that I try to
  >  impose on anyone that will listen:
  >  
  >      For every header file, there is a compiled .c file that includes
  >      the header file *first*.  This is true even if the .c file does
  >      nothing other than include the header file.
  >  
  >  If this policy is religiously followed, every header file is guaranteed
  >  to be standalone.
 
 I prefer (for large projects where regressions are likely) to have an
 explicit linting step for this. It's not that hard to write a makefile
 that emits and compiles a .c file for every .h file.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost