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
