From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Merging bignum to master Date: Thu, 16 Aug 2018 12:31:52 -0700 Organization: UCLA Computer Science Department Message-ID: References: <877ekwu1mn.fsf@tromey.com> <48742e8c-fffb-7fe0-bb12-2ce3dc171603@cs.ucla.edu> <837ekvlau2.fsf@gnu.org> <03f39b77-dc7a-5e52-69f1-a78efb3060f0@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1534447850 15370 195.159.176.226 (16 Aug 2018 19:30:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Aug 2018 19:30:50 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cc: eliz@gnu.org, ulm@gentoo.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 16 21:30:45 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fqNyn-0003rS-Me for ged-emacs-devel@m.gmane.org; Thu, 16 Aug 2018 21:30:45 +0200 Original-Received: from localhost ([::1]:57845 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqO0s-0002Oh-48 for ged-emacs-devel@m.gmane.org; Thu, 16 Aug 2018 15:32:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqO08-0002Ob-7Q for emacs-devel@gnu.org; Thu, 16 Aug 2018 15:32:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fqO06-0004t7-IL for emacs-devel@gnu.org; Thu, 16 Aug 2018 15:32:08 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43872) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fqO01-0004rL-Gb; Thu, 16 Aug 2018 15:32:01 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id ECEE6161496; Thu, 16 Aug 2018 12:31:58 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4w1Z0dhJ6RtP; Thu, 16 Aug 2018 12:31:58 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 169A2161489; Thu, 16 Aug 2018 12:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id o9OQOVdYjTzb; Thu, 16 Aug 2018 12:31:57 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id AC9451610C0; Thu, 16 Aug 2018 12:31:57 -0700 (PDT) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:228605 Archived-At: Richard Stallman wrote: > Why would we need both? Given --enable-bignums, which seems > fundametally to fit the purpose, is there really a reason for > --with-gmp? Do we support bignums other than using gmp? Yes and no. If by "using gmp" you mean linking to libgmp, some GNU packages do support bignums other than by linking to libgmp. However, every GNU package that I know of supports bignums either by linking to libgmp or by compiling code copied from some subset of the GMP sources. Here are some 'configure' options that GNU packages use to control this. As far as I can see, only Emacs master 'configure' follows the GNU coding standards. This suggests that in this area the standards are either too ambitious or are not clear enough; in either case they could use examples to cover some of the issues mentioned below. * Emacs (master branch) always supports bignums, and by default it uses libgmp if available and otherwise substitutes its own portable and slower implementation copied from the GMP source code. The default can be overridden with --with-libgmp / --without-libgmp. This follows the GNU coding standards, and it wouldn't make sense to for Emacs 'configure' to have an --enable-bignum option since bignums are always supported. * MPFR and Nettle always use bignums and by default always uses libgmp. Their 'configure' scripts have an --enable-mini-gmp option to cause their builds to use the portable and slower substitute. This doesn't follow the GNU coding standards, since --enable-mini-gmp doesn't affect user-visible features. * Coreutils supports bignums only as a build-time option that affects user-visible behavior. The Coreutils implementation always uses libgmp to support bignums if bignums are requested. Its 'configure' has a --with-gmp / --without-gmp option that works much like Emacs's --with-libgmp / --without-libgmp option, and that enables the bignum feature. It sounds like you're saying that Coreutils should rename its --with-gmp / --without-gmp option to --enable-bignums / --disable-bignums or something like that, since the option enables user-visible behavior. (Better yet, I suppose Coreutils should do what Emacs does and substitute its own portable implementation and use a --with-libgmp / --without-libgmp 'configure' option, though that'd be more work.) * GNU Common Lisp always supports bignums and requires libgmp, and has an --enable-oldgmp option that links to an older version of libgmp rather than a newer one. This usage doesn't follow the GNU coding standards, which say this should be a --with option. * GCC always uses bignums and requires libgmp, and if the platform lacks libgmp the GCC build process documents a procedure for you to download the GMP sources, build a libgmp of your own, and link to that. GCC's 'configure' program has a --with-gmp=DIR option that lets you tell the build procedure where libgmp is installed if it is neither supplied by your system nor built from sources in the way that GCC recommends. This --with-gmp=DIR option doesn't follow the GNU coding standards, which say "Do not use a @samp{--with} option to specify the file name to use to find certain files." I doubt whether this is an exhaustive survey, but it should give you a feel for some of the confusion in this area.