[asterisk-dev] policy for managing headers

[MENEAULT Maxime]

Luigi Rizzo wrote:
> I am trying to figure out the policy in asterisk for managing
> include files.  This is a bit critical for portability and cross
> builds to non-unix, because there are differences in the location
> name and content of include files. These differences are hopefully
> detected by 'configure', and better dealt with in a central place.
> 
Totally agreed.

> The status now is the following:
> * autoconfig.h is required (and forced by the top level Makefile)
>   for all files. This only defines constants resulting from autoconf
>   and manually set build options.
> 
> * asterisk.h is presumably required by all files (though some don't include it).
>   In turn, this includes asterisk/compat.h and asterisk/paths.h
> 
asterisk.h is not necessarily required by all files. The ones which 
don't need the exported symbols of asterisk.h don't have to include it. 
While including asterisk.h everywhere may not harm from a semantic point 
of view, it could make compilation slower and more hungry.

> * asterisk/compat.h includes a small set of basic headers
>   (right now inttypes.h sys/types.h stdarg.h) and then defines
>   some things in case they are not available in the system headers.
> 
> Other than this, most or all sources seem to include their own set
> of headers, often discarding the findings of 'configure'.
> 
> 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.
> 
Totally agreed, having a common header handling portability issues is 
completely justified. It alleviates developers which are not expert in C 
portability to get a almost portable code.
(I said 'almost' because unaware programmers may still raise alignment 
issues).
Apparently "asterisk/compat.h" was made for that but please note that 
Makefile also includes some OS dependent headers.
For instance 'ifeq ($(OSARCH),SunOS)' then 'solaris-compat' directory is 
also added as include search path.
The policy sounds strange because some OS-dependent things have been 
added in "asterisk/compat.h" too. The creation of new a include 
directory may be limited for the cases which it is really justified.

Note:
What is disappointing is that every "good" open-source program is always 
subject to the same portability problems. Most of the time it is due to 
outdated C libraries (either not conforming to standards or bugged). It 
should be the responsibility of OS maintainers to patch their bugged 
libraries not the responsibility of C programs.

Anyway, when you look at a server where Apache, MySQL and Asterisk are 
running, you'll have duplicated code on each of these binaries because 
they all have to handle the same portability issues.
The right solution would be to develop a shared portable server-side 
library that any open-source program would use instead of overloading 
their code.

Obviously, on machines where shared libraries are unavailable then the 
library shouldn't be linked directly but only the needed parts.
It could start from a fork of APR (Apache Portable Runtime) library 
which seems to be the most complete one and which is well licensed.

I know... it is a little out of scope...