>>>> "Malcolm" == Malcolm Purvis
Malcolm> It should be pointed out that this is slightly different
Malcolm> behaviour from the normal argument case. In that case if
Malcolm> --with-simple is not supplied then the shell variable
Malcolm> with_simple is "".
But the value for with_complex is "", just as in the simple argument
case. I would say that any behavior we specify for defaults of
with_complex_foo is an almost independent extension. True, we could
specify more defaults in the True/False cases, but I think that
violates the DRY (Don't Repeat Yourself) principle, and would depend
on coders of options to follow policy to get consistent results.
I would argue that in most cases the default for with_complex_foo
should be "", in most of the rest (known bugs in the feature) it
should be "no", and in a very few cases we could consider it being
"yes". (For example, if we move image support configuration to a
complex option --with-image-format, then Xpm and PNG support might
want to default to yes. The ones that we currently scream about
I'm thinking about adding a XE_VALIDATE_COMPLEX_OPTION. The idea is
that it would be used after completing detection of the features, and
if "$test with_complex_foo" = "yes" -a "$have_complex_foo"
!= "yes"; then
XE_DIE([Required complex foo support not available.])
and also loop over the complex foos and XE_DIE if the with_complex is
yes, but all of the have_complex_foo are no.
(Yes, I'm aware that we don't have consistent use of
have_complex_foo. That's why I'm not doing it in the attachments,
lotsa work. :-)
Malcolm> My proposal was in line with the traditional behaviour
Malcolm> but yours I think is better.
Good. This one I definitely like.
Malcolm> Your desiderata does not address this case:
Malcolm> 4) --with-complex=bar
I now think this behavior is incorrect, though not because it violates
the POLA (I found it surprising, but that's quite likely because I did
a lot of the work on the support for this feature). The argument is a
little more subtle (and maybe questionable).
In general we want XEmacs to have all the features configure can find.
If a user or a distro wants to defeat some, fine. But let them do it
explicitly. Surely you've seen the miles-long configure line that
SuSE uses in bug reports? Mike hasn't complained, and I doubt he
will, as long as our configure options are backward compatible with
his script. I'd like to start moving more of the optional features to
modules, which won't affect DIY users much, but will allow distros to
include everything while reducing their REQUIRE dependency libraries
to SUGGEST dependencies.
So overall I think that we should default to autodetect (in configure
option lingo, "") as much as possible. The above case is included in
Malcolm> You came up with this requirement with discussing
Malcolm> --with-error-checking a few months ago. The post can be
Malcolm> found at:
Malcolm> Is this case still a requirement?
No. If we think that behavior is appropriate we can set the defaults
to no,no,no,no,no!, easy enough. Note that --with-error-checking is
one of the few cases where setting the with_error_checking_foo
defaults to yes makes a priori sense. So that's kind of an
Here's code that implements what I'm proposing. The first attachment
is "test.ac", which simply is the first part of configure.ac with my
code substituted for XE_PARSE_COMPLEX_OPTION (nothing else needs to be
touched, good job Malcolm!) plus a single complex option "quux". The
second of course is the generated "test" script. The script doesn't
generate any configuration, of course, it just echoes the values of
the variables at the end. (test.ac does include your current version,
commented out, for comparison. They're quite different, I got
confused by shell quoting and ended up starting from scratch! :^)
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.