Re: Help with asterisk module needed

[Greg Troxel <gdt%lexort.com@localhost>]

Dima Veselov <kab00m%lich.phys.spbu.ru@localhost> writes:

> On 18.11.2019 0:01, Greg Troxel wrote:
>
>>> 2. Optionally this option should download and add app_mt.c to
>>> workdir/apps directory (for now i put it there by myself).
>>
>> The other approach is if you can build it separately with header files
>> installed by the main package, and it can then be a separate asterisk_mt
>> package.
>
> When I tried to add an option i was using "Buildlink methodology" and
> "How to create package from scratch" documents. Does suggested
> approach means new package which is bl3'ed to both asterisk16 and
> kannel? Doesn't it sound overloaded because we need to put downloaded
> .c in asterisk source tree and generally should be compiled inside it?

In an ideal world, asterisk would support plugins where you could 1)
build and install asterisk and then 2) build an additional file against
headers and libs that were installed in step 1.  But it sounds like it
doesn't.

If you really have to put the new file into the asterisk source tree
when you compile asterisk, then it makes sense to have an asterisk
package option to 1) add that file as a DISTFILE and 2) somehow patch
the build system, or hand-add steps.

Really this is not about the pkgsrc way vs some other way.  It's about
understanding if you can build the new file separately.

>>> I've added this to comms/asterisk16/options.mk:
>>> .if !empty(PKG_OPTIONS:Mkannel)
>>> #DEPENDS+=          kannel>=1.4.5:../../www/kannel.new
>>> .include "../../www/kannel.new/buildlink3.mk"
>>> PLIST.kannel=       yes
>>> .endif
>>
>> With bl3, DEPENDS is implicit and not used.
>
> I commented this out because I tried to use both. What should be used
> when I need to include headers, which are taken not from sources but
> from installed package?

bl3 links in both headers and libs, and add DEPENDS.

>>> I've added this to buildlink3.mk in www/kannel.new:
>>> BUILDLINK_INCDIRS.kannel=               /usr/pkg/include/kannel
>>> BUILDLINK_LIBDIRS.kannel=               /usr/pkg/lib/kannel
>>
>> That isn't right, because it says /usr/pkg, vs PREFIX.  
>
> I know, I did it directly for the test.

ok - perfectly fine to take shortcuts on the way to figuring things
out.  I just wanted you to realize this, and I wasn't sure.

>> I would look in doc/pkgsrc.txt and for other examples.
>
> Thank you, an example may turn to be very handy.

In /usr/pkgsrc ($PKGSRCIR, strictly):

  find . -name buildlink3.mk |xargs egrep INCDIRS

and you will see things like

./devel/ncurses/buildlink3.mk:BUILDLINK_INCDIRS.ncurses+=       include/ncurses

so just drop the /usr/pkg/ from your invocation.


>>> Any possible values of those do nothing:
>>> gwlib/gwlib.h is not found
>>
>>> gwlib/gwlib.h is located in /usr/pkg/include/kannel on installed
>>> package and in pkgsrc workdir.
>>
>> Look in work/.buildlink3 and see if you can find the symlinks and if
>> they seem right.
>
> Yes, they do
> [root@freon ~]$ ls -la
> /usr/pkgsrc/comms/asterisk16/work/.buildlink/include/kannel/gwlib/gwlib.h
> lrwxr-xr-x  1 root  wheel  37 Nov 17 22:54
> /usr/pkgsrc/comms/asterisk16/work/.buildlink/include/kannel/gwlib/gwlib.h
> -> /usr/pkg/include/kannel/gwlib/gwlib.h
> [root@freon ~]$ ls -la /usr/pkg/include/kannel/gwlib/gwlib.h
> -rw-r--r--  1 root  wheel  4013 Nov 17 21:39
> /usr/pkg/include/kannel/gwlib/gwlib.h

>> The other half is making sure asterisk's configure finds them.

So, those are being linked in as you say, but the using package has to

#include <kannel/gwlib/glib.h>

or else it has to add -I{$PREFIX}/include/kannel.

> I've tried to search where CFLAGS are located but asterisk seems to be
> extra tough for the beginner.

The instructions for the module should explain how to build.

These probably go in CPPFLAGS (for preprocessor) vs CFLAGS or CPPFLAGS,
or at least that's the norm.

Given that asterisk uses autoconf, the extra file probably should come
with a patch for configure.ac and some Makefile.

Agreed that the build system is complicated.

> Snatching at a chance I have one more case to ask about if you don't
> mind. There is a big patch named usecallmanager (usecallmanager.nz)
> for Cisco phones. I believe it may not be a standalone package because
> it patch lot of asterisk source files.
>
> It would be nice to have it as an option but I failed to apply it in
> any automated manner. It is proved working on NetBSD (I applied it
> manually to sources after make patch in pkgsrc).
>
> 1. It may not (and I believe shouldn't) be applied via patches/ due to
> multifile nature.
> 2. I failed to make an option, because we need here to download
> optional patch and patch it before applying.
> 3. It does not work in localpatches because of different base (running
> in asterisk source tree while localpatches need to run outside of it).
>
> What is the best strategy to make it automatically applying?

For things like this, often they are done with PATCHFILE which is like
DISTFILE but applied rather than extracted.