[asterisk-users] Trials with 1.4

[Russell Bryant]

Ira wrote:
> Well, in that case, having the dependency for Zaptel indicate you 
> need to build Zaptel and then run Configure would be useful instead 
> of including a list of dependencies running off the edge of the 
> screen that I can't read.  In my case, Zaptel 1.4 was installed and 
> running and I thought I ran configure again, but maybe not. What's 
> the downside of just saying, This is useless as Zaptel does not seem 
> to be installed? In 1.2 Zaptel was always built or maybe I just did 
> it right by accident the first time.  I'm not stupid, and I'm sort of 
> a Linux newbie, but it seems you're making 1.4 harder to install that 
> 1.2 and that seems a step backwards.  Is there a problem if I choose 
> to build Zaptel support on a machine without Zap installed?

Well, it was certainly the intent to make things easier.  Also, it isn't
possible to build Zaptel support in Asterisk without Zaptel installed.
  Installing zaptel installs the zaptel.h header file, which is needed
for compiling most of the zaptel related code.  That was true for 1.2 as
well.  In 1.4, this check is done by the configure script instead of by
the Makefile.

However, using the configure script to do these checks provides some
benefits.  Let me run through a list of some of the benefits of the 1.4
system of building Asterisk.

* In Asterisk 1.2, the Makefile had hard coded paths to look for header
files to determine whether a library was installed.  In Asterisk 1.4,
you can pass a path as an option to the configure script so that you can
build against libraries that are in non-standard locations.

* The 1.2 header file check did not guarantee that what is installed is
actually going to be able to be used by Asterisk.  The configure script
allows us to build a test program against each library to ensure that it
is actually usable, and that it is a compatible version.  So, in 1.2
where it was possible that a module would fail to build due to library
incompatibilities, this will not happen with 1.4.

* In Asterisk 1.2, the Makefiles would build every module it could,
without any way to control that.  In Asterisk 1.4, there is a console
menu interface for choosing which modules get built (make menuselect).
Furthermore, if modules can not be built due to an unmet dependency, the
menuselect interface gives you an easy way to see that, as well as find
out what libraries that module depends on.  Selections through this
interface are stored in a file (menuselect.makeopts), which can be
copied to other systems, or placed in /etc/asterisk.makeopts or
~/.asterisk.makeopts to ensure the same build configuration for multiple
builds.

I am hoping that these added features justify the fact that you have to
explicitly re-run the configure script to go check for newly installed
dependencies on the system.

-- 
Russell Bryant
Software Engineer
Digium, Inc.