[asterisk-dev] Zaptel Config

[Tzafrir Cohen]

On Wed, Aug 29, 2007 at 10:19:45AM -0500, Tony Plack wrote:
> 
> >
> > I frankly don't understand the purpose of the target "install-
> > include". Could you please explain what you think it is supposed to
> > do?
> >
> >
> Well, not that I am defending it (cuz I am not)... but the include for 
> zaptel is used for cross-compile when compiling asterisk.  Most of the 
> changes I am looking at deal with cross compile.  So we use the 
> "with-zaptel" and "with-tonezone" options in asterisk's configure 
> command to point to these in the build directory.

If you build --with-zaptel, then the current install-include is all you
need: zaptel.h defines the interface for userspace. And there's no extra
library to link with. Asterisk uses ioctls defined in zaptel.h .

(In zaptel 1.2 there was also torisa.h that had just one definision, and
was aparantly used just by torisatool. It was merged into zaptel.h in
1.4)

If you want to build vs. the libtonezone, then tonezone.h isnot enough.
You have to install libtonezone (.a or .so). So there's really no point
in installing that header file without the library itself.

> 
> Clearly, just doing a stock make works.  No issues there, it is when 
> you have people with cross compile scripts and these things change 
> that it impacts their scripts to build the systems.  That is where I 
> had issues.  Going from a glibc to uclib system.  Sure nuf, nano is a 
> very convenient way to fix this change in the script, 

Never. vi (I mean: this is the editor included in busybox)

That said, some of the changes made to 1.4.5 were to help
cross-building. I would hope that cross-building would require minimal
or no patching. Please reports you patches and help merge them.

> but the question 
> of permanency and changing INSTALL_PREFIX to DESTDIR is okay.  But is 
> this permanent?

Yes. Unless someone has a very good argument.

> 
> Most embedded systems are not that convenient to do a direct compile 
> upon them.
> 
> >> Lastly, includedir is pointed to ${prefix}/include.  It appears
> >> that prefix is by default root so include files are being placed
> >> in /include which is not correct. I believe that these should be
> >> exec_prefix which would place include files in /usr/include.
> >>
> >> Which of these need to be in the patch system.
> >>
> > # libdir, includedir and mandir are defined in makeopts (from #
> > configure).
> > # we use /sbin, rather than configure's $(sbindir) because we use
> > /sbin # for historical reasons. BIN_DIR:=/sbin LIB_DIR:=$(libdir)
> > INC_DIR:=$(includedir)/zaptel
> >
> >
> > Looking in makeopts, as suggested (the comment above was added for
> > greppers), you'll see:
> >
> >
> > prefix = /usr
> > exec_prefix = ${prefix}
> >
> > bindir = ${exec_prefix}/bin
> > datarootdir = ${prefix}/share
> > datadir = ${datarootdir}
> > includedir = ${prefix}/include
> 
> Agreed, that is my point, the includedir is not correct.  ${prefix} is 
> by default / (root).  

By which default?

Autoconf's default is that prefix's default is /usr . There are several
ways of overriding it at different levels.

Can you post the contents of your makeopts file?

> That places the include directory in the root of the fs during install.  
> By any fs standard, we NEVER have a /include.  We may have a /usr/include 
> but never a /include.
> 
> INC_DIR is fine, we just need includedir changed to make sure that it 
> is not /.
> 
> If you change this in configure to $(exec_prefix), it then seems to 
> place the include directory in /usr/include which is proper.
> 
> Unless I have missed something and we now need to have an include in 
> the root directory.

-- 
               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir