[asterisk-dev] policy for managing headers

[Luigi Rizzo]

On Fri, Nov 16, 2007 at 09:14:50AM -0600, Russell Bryant wrote:
> Luigi Rizzo wrote:
> > My proposal would be to let asterisk/compat.h deal with at least
> > the most common headers, or those that might have platform-specific
> > names or locations (most noticeably socket.h and the various
> > network-related ones).
> > 
> > Sources would still include their own "asterisk/somesubsystem.h"
> > headers, but at least this should reduce/simplify the management
> > of header files and reduce the chance of errors.
> > 
> > See a partial list below preceded by the number of occurrences in
> > the asterisk source tree.   
> > 
> > Comments/objections ?
> 
> I am fine with putting system headers in compat.h that have platform specific
> issues to be handled, or are included a large number of times in the tree, like
> the ones you pointed out.  You included some asterisk headers in the list,
> though.  I'd like to keep forcing all modules to include those.

those were there only because i was in a hurry and did not filter the list.

I intend to put in asterisk/compat.h ONLY SYSTEM HEADERS, and among
those ONLY THE MOST POPULAR or those almost always necessary
(sys/types.h, inttypes.h, std{io,lib,def}.h and possibly another
small set). This is the first step i am working on now.

All these headers are already directly included in 90% of the sources
(and probably, indirectly included in all files) so there should
not be a big difference in build times; in any case i will run
measurements to see what the difference is.

The next step is deal with certain optional subsets of functions e.g.
network stuff (socket.h, netdb.h and so on; threads-lock stuff;
database support; etc.) - system headers for those should be probably
included in "asterisk/network.h", "asterisk/lock.h" and so on, to
avoid repeating tests (and bugs) in multiple files.

>I don't necessarily want to get carried away and include _everything_ there. I

neither do I - besides, sometimes there might be conflicting
declarations so this is certainly something to avoid.

cheers
luigi