emacs-devel
[Top][All Lists]
Advanced

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

Re: Canonical location for emacs-version string in source tree?


From: Ken Raeburn
Subject: Re: Canonical location for emacs-version string in source tree?
Date: Thu, 20 May 2010 21:39:53 -0400

On May 20, 2010, at 14:01, Eli Zaretskii wrote:
>> From: Ken Raeburn <address@hidden>
>> Date: Thu, 20 May 2010 13:12:29 -0400
>> Cc: address@hidden
>> 
>> If you need to pick one place, then I think for now emacs.c is the right 
>> place.
> 
> Until someone moves it again, that is...

Well, yeah.

> Why was it moved, anyway?  I don't remember any discussions of that,
> apologies if I missed something.  The string was in version.el since
> forever.  The move subtly broke the MS-DOS port, btw, which I could
> have prevented if I just knew about it coming, which I didn't until
> now.

"emacs --version" would print out the version if it was set, otherwise ignore 
the option; it does this early in main(), before Lisp code is loaded.  The 
"make install" rule always runs "emacs --version" to figure out the DOC file 
name.  If you build with CANNOT_DUMP, the emacs binary that gets run hasn't had 
the basic Lisp code pre-loaded into it.  So "emacs --version" pops up a window.

Making the C code aware of the version number seemed like the easiest way to 
deal with it.  I'm sorry about the problem with the MS-DOS build; I took this 
approach because I thought that it (unlike trying to generate all 
version-string appearances from one canonical source) would be a simple, 
relatively minor change with little impact on the DOS/Windows builds.  (Using 
PACKAGE_VERSION presumes you're using the autoconf-based configure script.  
Extracting it from anywhere to make something visible to C requires running 
some external program like grep or sed.)  Apparently I underestimated the 
impact anyways.  I did discuss it a bit with Chong Yidong because he had made 
some comments a while back in response to my talking about the "--version" 
problem, but I didn't bring up my planned change on the list.

It seems like half the seemingly-minor tweaks I do relating to the build system 
wind up stomping on the DOS/Windows builds in some subtle way I didn't expect.  
*sigh*  Next time I'll try to make sure you're in the loop....  I don't have 
any more such changes planned right now though.

Ken


reply via email to

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