[asterisk-dev] Corydon76 Issue Deleted: 0006925, 04-28-06 17:49 Corydon76 Issue Deleted: 0006920

[Luigi Rizzo]

On Mon, May 01, 2006 at 04:45:58PM -0500, Kevin P. Fleming wrote:
> Luigi Rizzo wrote:
> 
> > Right now, we have duplicate build rules in the makefiles to link
> > in the required objects which are not in a library (and, at the
> > moment, some of these rules fail and/or require fiddling with
> > CPPFLAGS to include the right paths  -- e.g. in the case of ast_expr2),
> > and/or duplicated code in the source files (e.g. astman.c and
> > ael_parse.c) again to overcome problems with these object files.
> 
> And this raises another point: the 'library' contains code that may or
> may not have been built with MALLOC_DEBUG, DEBUG_THREADS, etc. That is
> going to be a difficult problem to solve; it's already bad enough when

and once again we don't care much about out-of-tree stuff.
The in-tree stuff at least can be done consistently, for
the rest it will be the responsibility of who uses the library
to build the app and the library in compatible ways.

> So far I see two examples of _applications_ that live in the Asterisk
> source tree that might benefit from being able to use a very small part
> of Asterisk as a library, but I don't see the benefit of having to move
> the entire API into a library at all. Most of the code that would live
> in that library is totally useless without a running Asterisk instance

if the entire API is overkill then move just part of it to the library,
and do it gradually if all at once is too unconvenient.

In terms of the Makefiles, the only difference will be individual
objects moving from the list used for the asterisk binary to the list
used to build the library.

E.g. all the wrappers for string handling and memory allocation,
logging, config file parsing, module loading could (gradually)
be moved there and be of general use.

enough for me. if you are not convinced, there is nothing
else i can say on the subject.

	cheers
	luigi