emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merging bignum to master


From: Paul Eggert
Subject: Re: Merging bignum to master
Date: Mon, 13 Aug 2018 18:41:16 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Richard Stallman wrote:
   > That being said, the distinction between --with-FOO and --enable-FOO has 
long
   > been a confusing area of the GNU coding standards -- as witnessed by the 
other
   > packages you're thinking about.

Is that because some cases have been handled erroneously?  Or is it
because some cases don't really fit into either --with or --enable?

In some cases it's erroneous coding. But more often, I think, it's because the two names are both plausible and developers and users are easily confused about which names to use.

For example, coreutils ./configure has a --with-gmp option, which causes two things to happen: first, 'expr' and 'factor' link to the GMP library (which is appropriate for --with-FOO) and second, these two programs support the feature of arbitrary-length integers (which is appropriate for --enable-FOO).

Strictly speaking, I supose the GNU Coding Standards require Coreutils to have both a --with-gmp option (to control whether the GMP library is used) and an --enable-bignum option (to control whether bignums are supported). But that would be more confusing than what Coreutils has now, which is a single option that controls both things, and which is more natural since the only reason you'd want to link to GMP is to have bignums, and if you want bignums with Coreutils the only way to get them is to link to GMP.

If the latter, I think we need to take the bull by the horns
and work out a good way to handle those cases, rather than forcing them
into one of two slots which they do not fit.

I hope that we needn't make the coding standards even more complicated than they already are in this area. When complexity causes confusion, adding more complexity is likely to cause more confusion.

I'd be more inclined to go in the direction Tom Tromey suggested, which is to no longer require a sharp distinction between --with-FOO and --enable-FOO since the distinction's confusion is more trouble than it's worth.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]