> 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 [EMAIL PROTECTED] NetKit Maintenance [EMAIL PROTECTED] (netkit-0.18 pre1 snap is up; expect pre2 to differ a fair amount though)
