Re: converting netkit to autoconf?

[Dan Kegel]

David A. Holland wrote:
>  > Here's what I ended up doing to cross-compile netkit-base and netkit-telnet:
>  > 
>  > I untar the netkit source tarball into a separate directory for
>  > each target processor type (bleh!).
>  > 
>  > I then use my own autoconf system to produce a custom MCONFIG,
>  > then copy that in to the source directory, and run make.
>  > I don't even bother with the configure that comes with netkit.
>
> This sounds like a complete waste of time. Since you're compiling from
> Linux to Linux, and probably the same versions too, it would be much
> faster to run configure for the host system and then edit MCONFIG.

Unfortunately, since I'm cross-compiling for an embedded system,
it's hard to run your configure on the host system.  Not all developers
have access to the hardware.

> Unlike the schlock emitted by autoconf, MCONFIG is human-readable and
> editable.
>
>  > >  > Has anyone converted netkit to use autoconf?
>  > > 
>  > > No, and certainly not for this issue: autoconf would not help, as the
>  > > problem has nothing to do with the configuration framework.
>  > > 
>  > > There are reasons autoconf wasn't used in the first place, too.
>  > 
>  > Can you give a few of them?  Also, has autoconf progressed now
>  > to a point where it'd be more appropriate than when you first
>  > considered it?
>
> (1) it's a canonical example of the principle that software is almost
> inevitably written using tools that are just not quite adequate for
> the job. autoconf is written in m4. This is a big liability.

I agree.

> (2) autoconf is, or was (but last I looked it hadn't changed)
> completely undocumented. That is, there's a lot of random
> documentation, but the important part (documentation of the test
> library) was completely missing.

Does http://www.gnu.org/manual/autoconf/html_node/Existing-Tests.html
meet your criteria for documentation?

> (3) The way autoconf is intended to be used, generating Makefiles from
> Makefile.ins and whatnot, is not the way I like to ship packages. When
> configure scripts screw up, which is more common than you probably
> realize, the user ought to be able to edit the results by hand *in one
> place*.

Readable configure scripts are good.  I often have to add 'set -x' in
configure to see where it went wrong.

>  > > Patches that remove the need for the signal semantics test (by
>  > > changing the code to use sigaction(2)) would probably be accepted.
>  > > 
>  > > However, I can't think of any way around the snprintf issue. Broken
>  > > snprintf implementations are not the problem they were a few years
>  > > ago, but they're still around and as people often seem to compile
>  > > netkit on strange platforms I'd prefer to keep that test.
>  > 
>  > I don't think you'd need to avoid that issue. autoconf can express
>  > every one of the tests you currently do in your hand-generated
>  > configure script.
>
> You were complaining that it couldn't cross-compile because it had to
> run some of its test programs. If you changed it to use autoconf, it
> would *still* have to run some of its test programs, and it *still*
> wouldn't cross-compile.
>
> So unless you have some kind of magic solution for that test (and some
> others)... you're blowing smoke.

Autoconf provides a standard way of overriding tests via the environment.
Fairly often, I can just use a standard set of overrides for any program
using autoconf, since they mostly use the same tests.

The alternative is hand-hacking MCONFIG, which is what I do for your stuff.

It's a shame autoconf's configure scripts are so gross.  If they were
more human-friendly, maybe more programmers would be willing to use it.

Maybe once Posix mandates Python :-)
- Dan