[asterisk-dev] install path of asterisk.h

[Luigi Rizzo]

On Tue, Nov 20, 2007 at 08:33:28PM +0200, Tzafrir Cohen wrote:
> Hi, thanks for your quick reply,
> 
> On Tue, Nov 20, 2007 at 10:14:02AM -0800, Luigi Rizzo wrote:
> 
> > With this in mind, i think we have three type of headers in asterisk
> > (i use the current name/location only as a reference, but they might
> > well deserve a renaming or relocation):
> > 
> >  1. those of general use that should be included by a large set of files;
> >     these include "asterisk.h", "asterisk/module.h", "asterisk/lock.h"
> >     and another small set of files;
> > 
> >  2. those exporting a very specific API, that a smaller set of files could
> >     be interested in. E.g. i think the various speech.h, say.h, rtp.h
> >     and so on fall in this second category;
> > 
> >  3. those for internal use only, whose role is to export prototypes for
> >     functions defined in one file and used in another one. Such functions
> >     are the various foo_init() etc. (at the moment they are in the same
> >     foo.h that exports the API for module foo, but this is a mistake because
> >     clients are normally not interested in them).
> >     I think these "internal" interfaces should be listed in a small set
> >     of header files for system use.
> > 
> > Clearly the boundary between #1 and #2 is a bit fuzzy but the extremes
> > should be relatively clear.
> > 
> > Accordingly, we could think of putting these files in 3 different
> > directories, e.g. #1 in include/asterisk/*h, #2 in include/asterisk/modules/*.h,
> > and #3 in include/asterisk/private/*h to make it clear to the developer
> > what they are for.
> 
> Is there any API provided by Asterisk that is not for modules?

#3 is typically for the core - look at the functions in asterisk.h
marked as 'Provided by ...'. In a perfect world they should go
away and be replaced by initializers or destructors.

> Is there a difference between what in-tree modules should see and what
> external modules should see?

probably not.

> Should private includes reside under include/ ? Is there any such
> include file that needs to be shared accross directories?

it depends on where you put the information. As i said in a perfect
world they should not exist, in a standard world they are such a small
number that wherever you put them is inessential.

cheers
luigi