Re: Identify XEmacs build from Mercurial changeset

BTW, it occurs to me that the whole approach of setting this in version.sh is probably excessively complicated. We did it that way originally because it was done on the server. Would it be more portable to just set a variable XEMACS_HG_NODEID=`hg identify` in the Makefile and add `-DXEMACS_EXTRA_NAME=" (+hg:${XEMACS_HG_NODEID})"' to CFLAGS or so? (And eliminate the extra_name variable. I can imagine other variants, using a different name for automatically generated version info and reserving extra_name to the user.) Michael Sperber writes: There's nothing that horrible with a little redundancy xemacs_extra_name= xemacs_extra_name="hg:abcdef0123" for Windows, is there? The *code* in my suggestion is fragile, but once it works there's no reason to change it ever, unless you change the name of the option or the whole file format. The file format in yours is fragile in itself; it depends on ordering and lack of a trailing newline. It's also not extensible to a second keyword. I don't like that. The point of xemacs_extra_name is to flag non-release builds. I agree that we should know the revision that the release was built from, but we already know that: it's tagged with an identifier built from the version number, which is reserved to the maintainer and unique by construction. To be pedantic, it doesn't tell you that, because the repo is by definition local. You do not know whether the particular revision is available anywhere else. Regarding the question of internalizing the diff and/or getting a list of modified files, yes, just having the local mods flag should be enough; we get the reporter to do a diff. _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches