[Hamlib-developer] Re: hamlib development

[<f4...@fr...>]

[message Cc: to hamlib-developer for insight on autoconf]

Robert Steinhaeusser wrote:
> The hamlib-1.1.1-release compiles fine, but I've had problems with the
> current CVS version. configure stopps:
> > config.status: error: cannot find input file:
> winradio/linradio/Makefile.in

That's really weird. Can you check, right after a fresh check out, 
if winradio/linradio/Makefile.in and kachina.Makefile.in are missing?

My guess is that's related to the version of autoconf/automake/libtool.
see below.

> > reiner:/usr/src/hamlib # make
> > cd . && automake --gnu Makefile
> > automake: couldn't open `configure.in': No such file or directory
> > make: *** [Makefile.in] Error 2
> > reiner:/usr/src/hamlib #

Okay, here we go. Hamlib-1.1.1 has been developped using autoconf 2.13,
automake-1.4 and libtool-1.3.5 as far as I remember. Well, the big change
with the CVS rep is we're now using autoconf 2.52, automake-1.4p4(waiting
for automake-1.5) and libtool-1.4b. Bleeding edges can get really bloody 
sometimes.
So, the biggest change is between autoconf-2.13 to >2.50. configure.in is
no more. Since some macros have been redesigned, autoconf maintainers
decided to rename this file to autoconf.ac, which clears up at the same time
the ambiguity with Makefile.in and anything.in different purpose extension.

So if you'd like to tinker with configure.ac or any Makefile.am files,
you have to upgrade to these latest versions. Now, for those who are
not interrested in Hamlib maintenance, just testing, I have no easy
solution for you yet (sorry). The best one would be to have an option 
to pass to configure, and generate Makefiles which won't try to run
autoconf/automake on their own (kind of --no-recheck). Please, if you 
know how to do this, let me know. My quick work around consists in creating 
shell scripts in hamlib root directory, with names 
automake,autoconf,aclocal,autoheader
containing something like this:

        #!/bin/sh
        exec ./missing `basename $0` $*

NB: libtool-1.4b-3 (debian) works fine under Linux, but appears to break
compilation under other systems (OS X, cygwin). Error is "LT_EMALLOC used with
wrong number of args". Hopefully libtool-1.5 will come out before hamlib-1.1.2. 
In the meantime, help is more than welcome!

I hope we'll see better days soon. Actually, this is my first time
using autotools, and I'm still learning the arcanes of these very powerful
tools. In the end, it's worth it: portability of Hamlib to *any* system!

> I just read the FT847 manual and found out it only needs a nullmodem
> cable
> for CAT operations. I might be lucky and have a ready cable in the
> shack;
> I'll go and test it

Fine business Robert, as would say our dear GB friends. If you don't manage to
to build the CVS version, and still want to do a  quick test, 
hamlib-1.1.1 should be okay with the FT847. Frank has tested it.
You may run rigtest and rigctl in the tests/ subdir. Note with 1.1.1,
you have to modify the C file to specify you rig number.
Also, if you wanna test without installing Hamlib, you'll have to
set your LD_LIBRARY_PATH accordingly. Provided topsrc is an env variable
holding the path of the Hamlib source dir, add 
$(topsrc)/src/.libs:$(topsrc)/yaesu/.libs:$(topsrc)/anyrig/.libs to it.
Hopefully, this LD_LIBRARY_PATH trick won't be needed in future versions of 
automake/libtool.

Let me know how far you get. I'll be out of town this week-end, so we'll
have to postpone the (still unsuccessful)sked to next monday. I'm not very
used to HF bands, but I'm learning. With my poor conditions (end-fed antenna),
I've made QSO with 4X this week, and KA1 in CW yesterday night (too bad this
guy didn't know what QRS means). Exciting sure, but there's room for 
improvements. Once I have work out this, maybe we can establish
a weekly Hamlib net!


73, Stephane