[Asterisk-Dev] Dev call 1.2 release discussion

[Tzafrir Cohen]

On Mon, May 09, 2005 at 08:20:11PM +0200, marek cervenka wrote:
> this is not usefull for automatic packaging

Maybe, maybe not.

I have no experience with scorns, so I cannot comment on it. However
some of the current problems with packaging Asterisk:

* The zaptel kernel modules

  It appears there's nothing much to do about that. Unless someone can
	suggest and code a useful userspace timing source, the problem is here
	to stay for a while

* fighting the auto detection

  When I build a package I want to get exactly what I want. I should
	have a totally reproducable build. Asterisk's makefile does a lot of 
	autodetection on its own, but there is no way to override it, aside
	from patching the makefile

* There's also no way to checge the pathes it searches aside from
  patching the makefile. 

The result is that the makefile is heavily patched. Currently the Debian
package has quite a few patches in the Asterisk package. And the
makefile is common to at least two of them. With the apps subdirectory
it is even worse. It would have been common for more, but we were lazy, 
and changed a patch instead of adding changes as a different patch.

A small change I really need is to get the autodetection into a separate
file and make it as easy to override as possible.

Let's take the following example (slightly old, but the same syntax is
still around)

  
	CFLAGS+=$(shell if [ -f /usr/include/linux/zaptel.h ]; then echo "-DZAPTEL_OPTIMIZATIONS"; fi)
	CFLAGS+=$(shell if [ -f /usr/local/include/zaptel.h ]; then echo "-DZAPTEL_OPTIMIZATIONS"; fi)

As the Debian packager I have ways of guaranteeing the zaptel source
will be there. As it happens, this path is now the current location of
zaptel.h in the debian package zaptel-source, but it was in
/usr/src/zaptel/modules/zaptel.h previously. Let's assume I want to take
zaptel.h from there. Or from /usr/src/linux-`uname -r`/include , or some
other crazy thing I want to do as a packager (someone who automates
building packages).


What would I like to see for that example:

  # in the "user config" part of the makefile

  # uncomment this to disable zaptel optimizations
	# (or build with 'make ZAPTEL_OPTIM=0')
	#USE_ZAP_OPTIM=0
	ZAP_OPTIM_SEARCH_PATH:=/usr/src/linux/include /usr/local/linux/include
	# why a variable for the file name? maybe this will one day be 
	# zaptel/zaptel.h ?  Though I'm not so sure this is a good idea
	ZAP_OPTIM_SEARCH_FILE:=zaptel.h
	ZAP_OPTIM_CFLAGS:=-DZAPTEL_OPTIMIZATIONS
	
  # ... later on
	
	# Here we will eventually include autoconf's 
	# discoveries that will override such variables from the header.
  # include config.mk 

  # ... later on
 
  ifneq (0,$(USE_ZAP_OPTIM))
	  # previous autodetection magic
	  ifneq (,$(shell for dir in $(ZAP_OPTIM_SEARCH_PATH); do if test -f $$dir/$(ZAP_OPTIM_SEARCH_FILE); then echo $dir; break; fi))
			CFLAGS += $(ZAP_OPTIM_CFLAGS)
		endif
	endif

Now I generally don't need to mess with the magic down below in the
makefile. If I just want to mess with the pathes I can override
variables from the make command-line or from the environment. The next
logical step is to use autoconf to automate all of this magic, but then
it will be mostly a matter of writing the file, as the makefile will
already be ready to use the configuration from it.

> if we want put asterisk to any major distro(=large user base), then we 
> need easy system for automatic building

Asterisk is already in Debian. There seems to be a freebsd port. I don't
know if there is any intention of getting it into Fedora-extras any time
soon.

> 
> another holy quest is get zaptel to vanilla kernel

[0] I use gnu make specific syntax. I don't think it is such a problem
    to use gnu make as a build requirement, because I find it hard to 
		find a platform where a unix make exists and gmake is not readily 
		avilable, and that would be interesting for asterisk packagers.

-- 
Tzafrir Cohen     icq#16849755  +972-50-7952406
tzafrir.cohen at xorcom.com  http://www.xorcom.com