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. _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users