Re: --with-foo= vs. FOO=${FOO:-foo_default}

[Russ Allbery]

Ben Pfaff <address@hidden> writes:
> Russ Allbery <address@hidden> 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 <address@hidden>
Technical Lead, ITSS Infrastructure Services, Stanford University