Ben Pfaff <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes:
>> This seems like obviously bad advice to me. How is one expected to >> handle something like specification of a default paper size unless >> there's a user switch somewhere? >> Surely the GNU coding standards aren't arguing that editing a cryptic >> configuration file is an improvement over a configure switch? > In my experience, a cryptic configuration file is almost always an > improvement over a configure switch. To change a configure switch, I > have to find the program's source code and figure out and go through its > configuration, compilation, and installation procedure. To change a > configuration file, I just have to find it and edit it, and if it's > well-written then it even has a comment above each option explaining my > choices. You've very much missed my point, I think. Obviously, as many things as possible should be run-time configurable. That's not in question. But sometimes they're simply not, for one reason or another. It's all nice and well to tell people that everything should be run-time configurable, but that's easier said than done, and sometimes it's just not worth the restructuring of the code that would be necessary. Now what should we do? I'm not talking about run-time configuration files. The pre-autoconf solution was to make people edit a C header file and follow somewhat cryptic instructions in comments, or edit a Makefile and set defaults. Surely people don't think we should go back to that? A configure switch is *so* much cleaner. Here are two excellent examples from INN: --with-log-compress=METHOD Log compression method [gzip] --with-max-sockets=N Maximum number of listening sockets in innd The first switch controls some wide-ranging changes to shell scripts. It's a rarely-used option, since most people have gzip. It could conceivably be made a run-time option, but why bother? If you don't have gzip, you're going to know that at compile time and select compress, and once you've built the package, the chances of your preference changing are somewhat remote. If you were going to go build gzip for INN, you would have done that originally (and there are so few people without gzip that it's not worth taking much time to make things nicer for them). The second switch is something that certainly should be determined at run-time, but for various reasons related to how the IPv6 support was handled just isn't easy to do that way. Sooner or later it will be fixed. In the meantime, isn't this rather better than making people go edit a header file if they have to change it to support a larger server? Editing a file in the source tree is a *bad* solution for a whole bunch of reasons, not the least of which is that it's much more difficult to script. I have a bunch of tools to help me remember configure options and build a package with the same options as before, and it works great when people use configure options for things like this (and ideals aside, there are very few major software packages that do not have a handful of options like this). Patching random header files requires generating patches that tend not to apply to the next version. -- Russ Allbery <[EMAIL PROTECTED]> Technical Lead, ITSS Infrastructure Services, Stanford University
