Re: converting netkit to autoconf?

[David A. Holland]

 > 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.

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.

(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.

(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*.

Yadda yadda. You're probably not going to listen to me, and I'm not
likely to change my mind.

 > > 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.

-- 
David A. Holland       address@hidden
NetKit Maintenance     address@hidden
(netkit-0.18 pre1 snap is up; expect pre2 to differ a fair amount though)