re: Automated report: NetBSD-current/i386 build failure

[christos%zoulas.com@localhost (Christos Zoulas)]

On Jun 4,  6:07am, mrg%eterna.com.au@localhost (matthew green) wrote:
-- Subject: re: Automated report: NetBSD-current/i386 build failure

| FWIW, yes, i did do this, both before committing and after i
| heard a report it wasn't working for chuq.
| 
| i still was unable to reproduce it, and while christos commited
| one fix, i still think forcing that code to look at _our_
| headers first before cddl ones is better than the hacks we've
| added to the cddl ones to be usable in non-cddl code contexts,
| is also the right thing to do.

Let me explain my way of thinking about this:

There are two kinds of system header files:
	1. "infrastructure" headers that provide base definitions and
	   other stuff that other headers use (systm.h)
	2.  "feature" headers that provide a specific feature (proc.h).

The solaris ones generally augment ours; the template should be;

solaris/foo.h:

#ifndef SOLARIS_SYS_FOO_H
#define SOLARIS_SYS_FOO_H

#include_next <sys/foo.h>

/* More definitions */

#endif /* SOLARIS_SYS_FOO_H *?

Now there caaes where the solaris headers expose more stuff than ours,
so we need to include more of our system headers from theirs. When that
happens the rule should be that:

Their infrastructure headers should not include our feature headers,
but can include our infrastructure headers, otherwise we end up with
circular dependencies. Violations to the rule should be kept to a minimum
and tested carefully.

In the general case, if we want the augmented symbols we should include
the solaris ones first in the search path.

christos