From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.auctex.devel,gmane.emacs.devel Subject: Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release. Date: Thu, 06 Dec 2012 10:46:34 +0900 Message-ID: <87hao02br9.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87fw3m1di7.fsf@thinkpad.tsdh.de> <871uf5sgj4.fsf@thinkpad.tsdh.de> <87hao0mw44.fsf@thinkpad.tsdh.de> <87ip8gd1al.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1354758406 24202 80.91.229.3 (6 Dec 2012 01:46:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2012 01:46:46 +0000 (UTC) Cc: auctex-devel@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: auctex-devel-bounces+gead-auctex-devel=m.gmane.org@gnu.org Thu Dec 06 02:46:58 2012 Return-path: Envelope-to: gead-auctex-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TgQY9-0002Kj-Uj for gead-auctex-devel@m.gmane.org; Thu, 06 Dec 2012 02:46:54 +0100 Original-Received: from localhost ([::1]:60954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgQXx-0000cN-Nu for gead-auctex-devel@m.gmane.org; Wed, 05 Dec 2012 20:46:41 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgQXv-0000cF-3o for auctex-devel@gnu.org; Wed, 05 Dec 2012 20:46:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TgQXt-0001XL-C5 for auctex-devel@gnu.org; Wed, 05 Dec 2012 20:46:39 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:35902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgQXs-0001WH-R9; Wed, 05 Dec 2012 20:46:37 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id A272A9708F2; Thu, 6 Dec 2012 10:46:34 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 67B111A31E0; Thu, 6 Dec 2012 10:46:34 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 X-BeenThere: auctex-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion list for AUCTeX developers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: auctex-devel-bounces+gead-auctex-devel=m.gmane.org@gnu.org Original-Sender: auctex-devel-bounces+gead-auctex-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.auctex.devel:2793 gmane.emacs.devel:155314 Archived-At: Stefan Monnier writes: > Can you describe how does the XEmacs-package-building relates to the > VCS repository? It doesn't restrict the repository in any way. The XEmacs package build system puts the packages into a specific layout (basically similar to an installed GNU Emacs of 19.x vintage, without the bin directory and with no libraries in the top level of the lisp/ directory, only subdirectories containing packaged libraries). The build system has sufficient flexibility to handle the AUCTeX source layout, and any future variation of it that I can imagine without hallucinogens. Updating it to handle future changes to AUCTeX's source layout is *purely* our problem. AUCTeX's build system does the same job in a different way. The two systems have different purposes. AUCTeX's is to avoid a requiring that its users and developers maintain a specific build environment just for XEmacs packages. Ours is to guarantee that our distributed packages are built in a controlled environment. As far as I can see, neither of these should affect GNU Emacs or GNU ELPA for quite a while. I think the Emacs maintainers should be vaguely aware of the build environment issue, because there's a possibility that as ELPA expands and becomes widely used, inconsistencies among packages distributed stand-alone may arise. However, since Emacs has a policy of eschewing support for non-GNU systems when that conflicts with the optimal support for GNU, I think ELPA will find it much easier to support AUCTeX's build system directly. It's difficult for us because it depends on utilities that are normally not present on Windows, for example.