Re: [Iaxclient-devel] [PATCH] autoconf/automake support and various fixes

[Steve K. <st...@st...>]

Steve Kann wrote:

> Mikael Magnusson wrote:
>
>> Steve Kann wrote:
>>
>>>
>>> OK, I've tried this stuff out, and I encourage others to do so as well.
>>>
>>> It seems to be pretty flexible, and I've figured out how to make it 
>>> work.  (to use the patch as-is, you may need to add codec_alaw.[ch] 
>>> to lib/Makefile.am).
>>> ...
>>
>>
>>
>> I have updated my patches against current CVS (yesterday actually) 
>> and added codec_alaw to lib/Makefile.am.
>>
>> Some other changes:
>>
>> * Defaults to using local portaudio library, since it contains some 
>> modifications.
>> * Disabled IAX1 support in configure.ac, it isn't working.
>> * Commented out inclusions of winpoop.h, which definitions aren't used.
>> * Fixed format of some help strings in configure.
>> * Build Mac OS X resources in simpleclient/iaxcomm/Makefile.am and 
>> simpleclient/iaxphone/Makefile.am (untested).
>> * Added some missing files to distribution. Now only ChangeLog and 
>> NEWS are needed before using make dist.
>>
>
> A couple more problems:
>
> Regressions:
> 1) MACOSX is not defined when compiling libiax2 sources on Mac OS X, 
> so iax.c won't compile because of header issues.
>    I see you are doing the config.h thing, but libiax2 doesn't look 
> for this, so we need to put the main OS stuff on the commandline..
>
2) Make dist seems to miss a bunch of files.  Basically do make dist, 
then do a  diff -r|grep "^Only" on the unpacked tarball vs the CVS 
directory.  You'll find:

a) For several of the included libraries, we miss much of the original 
distribution.  Mostly, this is because we don't use these files, but I 
think we should include them anyway in a release tarball?

b) WinIAX is not included, presumably because I did make dist on linux 
after doing ./configure there?


> New feature questions/problems:
>
> 1) Here's why I'm not getting a .DLL on Win32:
>
> *** Warning: linker path does not have real file for library -lwinmm.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libwinmm and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /lib/w32api/libwinmm.a
>
> *** Warning: linker path does not have real file for library -lwsock32.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libwsock32 and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /lib/w32api/libwsock32.a
> *** The inter-library dependencies that have been dropped here will be
> *** automatically added whenever a program is linked with this library
> *** or is declared to -dlopen it.
>
> *** Since this library must not contain undefined symbols,
> *** because either the platform does not support them or
> *** it was explicitly requested with -no-undefined,
> *** libtool will only create a static version of it.

2) On Win32, I guess I don't have the xrc stuff needed to build iaxComm, 
but ./configure doesn't seem to find this, so iaxComm fails because it 
can't find "wx/xrc/xmlres.h".  But maybe this is because I had to 
specifically list the clients I wanted with --enable-clients="iaxcomm 
testcall" there, because otherwise it failed because WinIAX sources 
weren't in the dist.


3) If we're going to do this big cleanup, in addition to dropping IAX1 
support, we probably ought to also drop the un-maintained clients:

wx: My first wx-windows based client.
iaxphone: Michael's first commit of iaxcomm, before he changed the name 
(IIRC)
win32 directory/"simpleiax": unmaintained

Maybe:
WinIAX: If it can compile with this new system, we might keep it, but I 
dunno if Faizan is going to maintain it..

Keeping only:
testcall: might as well keep this, it's handy for development/testing, 
but I wouldn't install it..
tkphone: Just contributed by Stephen Uhler, and a good example of the 
"coprocess" model.
iaxComm: The full-featured cross-platform IAX softphone.