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

Kevin P. Fleming kpfleming at digium.com
Mon May 1 14:45:58 MST 2006


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
out-of-tree modules are built without knowing the actual configuration
that was used to build Asterisk.

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
to supply data to it, and in fact we are currently making changes to the
module API that will make it _harder_ to use format/codec modules
outside of Asterisk itself (not intentionally, but still occurring).



More information about the asterisk-dev mailing list