From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs trunk binary on Dropbox Date: Wed, 02 Oct 2013 12:00:57 +0900 Message-ID: <87vc1gqsuu.fsf@uwakimon.sk.tsukuba.ac.jp> References: <86vc1htogy.fsf@somewhere.org> <86li2d5qfi.fsf@somewhere.org> <83bo39dlph.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1380682889 27135 80.91.229.3 (2 Oct 2013 03:01:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Oct 2013 03:01:29 +0000 (UTC) Cc: Sebastien Vauban , Eli Zaretskii , Emacs development discussions To: Dani Moncayo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 02 05:01:33 2013 Return-path: Envelope-to: ged-emacs-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 1VRCgu-00022r-Q7 for ged-emacs-devel@m.gmane.org; Wed, 02 Oct 2013 05:01:32 +0200 Original-Received: from localhost ([::1]:33641 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRCgt-00049n-Va for ged-emacs-devel@m.gmane.org; Tue, 01 Oct 2013 23:01:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRCgl-00048Y-Cz for emacs-devel@gnu.org; Tue, 01 Oct 2013 23:01:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VRCge-0001JM-ND for emacs-devel@gnu.org; Tue, 01 Oct 2013 23:01:23 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:54325) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRCgT-0001H0-R5; Tue, 01 Oct 2013 23:01:06 -0400 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 23C9F970A0A; Wed, 2 Oct 2013 12:00:58 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id DD6501A348A; Wed, 2 Oct 2013 12:00:57 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" 182d01410b8d 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: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163787 Archived-At: Dani Moncayo writes: > It would be nice if I could specify the bzr revno manually, for > example as a parameter to "configure" or "make", because having to > keep using bzr just for this little thing would also be too bad. I don't own the code so won't quote it here, but XEmacs has a file named "version.sh" which contains mostly static information about the version: current major and minor, most recent patchlevel, beta status, and something called "extra version info". I forget how it's done (I think it's in configure) but if hg is available, just do "hg id -i -n >> version.sh", and then make includes that file so that the version values are available in Make variables. They may also be substituted into config.h, I forget. The latter would probably be easiest: add a "version-extra-info" building variable to Lisp (in C), and add #define VERSION_EXTRA_INFO @@VERSION_EXTRA_INFO@@ to config.h.in, and let configure do its thing using the bzr revision number or revision id or both (I prefer both since people using bzr who are off the mainline with local changes won't have useful revnos). If you use a shell/make script, the tricky part is that it's essential that the "extra_version_info=" line be last and unterminated with a newline. Presumably some similar could be done with lisp/version.el or whatever as well. I don't see why the maintainers would object to this, so feel free to come up with a patch.