minor observations on Mac build of 22.0.99

minor observations on Mac build of 22.0.99

[Ken Raeburn]

I grabbed the 22.0.99 pretest and built it on a couple of Macs, one  
PPC and one Intel.  Both builds went just fine, and Emacs installs  
and (so far) runs fine as well.

A couple observations, neither of which seems critical to address for  
the release:

1) The installer adds files to /Applications/Emacs.app if it already  
exists, rather than replacing that tree completely.  On one of my  
machines, /Applications/Emacs.app/Contents/MacOS/bin now contains  
both emacs-22.0.91 and emacs-22.0.99.  If I move Emacs.app to the  
trash before installing, the result is cleaner, with just  
emacs-22.0.99.  (Similarly for other files: the old DOC file, some  
elisp and image files, etc., were left over from the old version.)

Is this intentional or expected, or a bug?

2) Out of curiosity, I compared the Intel and PPC trees with diff.   
Not only were the executables different, which was expected of  
course, but also leim/quail had differences in the .el.gz and .elc  
files.  Picking a .el.gz file at random, the only difference I found  
was in the date stamp.

Are these files in fact going to be identical aside from the date  
stamp in all builds?  If so, perhaps like the .elc files in the lisp  
tree they should be pre-generated for the release and pretest  
distributions.

Ken

Re: minor observations on Mac build of 22.0.99

[Andreas Schwab]

Ken Raeburn <raeburn@raeburn.org> writes:

> 1) The installer adds files to /Applications/Emacs.app if it already
> exists, rather than replacing that tree completely.  On one of my
> machines, /Applications/Emacs.app/Contents/MacOS/bin now contains  both
> emacs-22.0.91 and emacs-22.0.99.  If I move Emacs.app to the  trash before
> installing, the result is cleaner, with just  emacs-22.0.99.  (Similarly
> for other files: the old DOC file, some  elisp and image files, etc., were
> left over from the old version.)
>
> Is this intentional or expected, or a bug?

What do you mean with "installer"?  Do you use make-package?

> 2) Out of curiosity, I compared the Intel and PPC trees with diff.  Not
> only were the executables different, which was expected of  course, but
> also leim/quail had differences in the .el.gz and .elc  files.  Picking a
> .el.gz file at random, the only difference I found  was in the date stamp.

The files could be compressed with `gzip -n' which would leave out the
time stamp.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: minor observations on Mac build of 22.0.99

[Ken Raeburn]

On Apr 30, 2007, at 06:25, Andreas Schwab wrote:
> Ken Raeburn <raeburn@raeburn.org> writes:
>
>> 1) The installer adds files to /Applications/Emacs.app if it already
>> exists, rather than replacing that tree completely.  On one of my
>> machines, /Applications/Emacs.app/Contents/MacOS/bin now contains   
>> both
>> emacs-22.0.91 and emacs-22.0.99.  If I move Emacs.app to the   
>> trash before
>> installing, the result is cleaner, with just  emacs-22.0.99.   
>> (Similarly
>> for other files: the old DOC file, some  elisp and image files,  
>> etc., were
>> left over from the old version.)
>>
>> Is this intentional or expected, or a bug?
>
> What do you mean with "installer"?  Do you use make-package?

Oh, yes, sorry.  I used make-package --self-contained, which produced  
EmacsInstaller.dmg, a disk image containing a Mac installer package  
file.

>> 2) Out of curiosity, I compared the Intel and PPC trees with  
>> diff.  Not
>> only were the executables different, which was expected of   
>> course, but
>> also leim/quail had differences in the .el.gz and .elc  files.   
>> Picking a
>> .el.gz file at random, the only difference I found  was in the  
>> date stamp.
>
> The files could be compressed with `gzip -n' which would leave out the
> time stamp.

Sorry again :-).  There's a line near the top of the .el file  
containing a date stamp of when the file was generated.  So the file  
contents differed, but not in any way that should've been important.

Ken

Re: minor observations on Mac build of 22.0.99

[Andreas Schwab]

Ken Raeburn <raeburn@raeburn.org> writes:

> On Apr 30, 2007, at 06:25, Andreas Schwab wrote:
>> Ken Raeburn <raeburn@raeburn.org> writes:
>>
>>> 1) The installer adds files to /Applications/Emacs.app if it already
>>> exists, rather than replacing that tree completely.  On one of my
>>> machines, /Applications/Emacs.app/Contents/MacOS/bin now contains  both
>>> emacs-22.0.91 and emacs-22.0.99.  If I move Emacs.app to the  trash
>>> before
>>> installing, the result is cleaner, with just  emacs-22.0.99.
>>> (Similarly
>>> for other files: the old DOC file, some  elisp and image files, etc.,
>>> were
>>> left over from the old version.)
>>>
>>> Is this intentional or expected, or a bug?
>>
>> What do you mean with "installer"?  Do you use make-package?
>
> Oh, yes, sorry.  I used make-package --self-contained, which produced
> EmacsInstaller.dmg, a disk image containing a Mac installer package  file.

I haven't seen that behaviour myself (neither in 10.3 nor 10.4), but I
don't use --self-contained.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: minor observations on Mac build of 22.0.99

[Richard Stallman]

    Are these files in fact going to be identical aside from the date  
    stamp in all builds?  If so, perhaps like the .elc files in the lisp  
    tree they should be pre-generated for the release and pretest  
    distributions.

They definitely should be.  I did not realize this was not already the
case.  Can someone please fix this and ack?

Re: minor observations on Mac build of 22.0.99

[Glenn Morris]

Richard Stallman wrote:

>     Are these files in fact going to be identical aside from the date  
>     stamp in all builds?  If so, perhaps like the .elc files in the lisp  
>     tree they should be pre-generated for the release and pretest  
>     distributions.
>
> They definitely should be.  I did not realize this was not already the
> case.  Can someone please fix this and ack?

It's not apparent from what you quote, but you do know this refers to
only a small number of files in the leim/quail directory, right? The
associated .el files are not even included with an Emacs tarball at
present, because they are generated from various dictionary files at
build time.

I don't know if there is any reason for this besides space-saving, but
it was not considered a problem two years ago:

emacs-devel, 2005/04/13, "make-dist doesn't distribute some quail files"
http://lists.gnu.org/archive/html/emacs-devel/2005-04/msg00475.html

Re: minor observations on Mac build of 22.0.99

[Ken Raeburn]

On Apr 30, 2007, at 21:04, Glenn Morris wrote:
> It's not apparent from what you quote, but you do know this refers to
> only a small number of files in the leim/quail directory, right? The
> associated .el files are not even included with an Emacs tarball at
> present, because they are generated from various dictionary files at
> build time.

It looks like the installed package has 21 .elc files in the quail  
directory that aren't included in the distribution.  (And 21 .el  
files, I assume, but haven't verified.)

> I don't know if there is any reason for this besides space-saving, but
> it was not considered a problem two years ago:
>
> emacs-devel, 2005/04/13, "make-dist doesn't distribute some quail  
> files"
> http://lists.gnu.org/archive/html/emacs-devel/2005-04/msg00475.html

I assume the issue is space versus build time.  I guess the question  
is just where to draw the line.  As far as I recall offhand, all the  
other generated files that are independent of configuration options  
and platform are all the other .elc files and a couple  
regenerated .el files, and we include those in the distribution.  Not  
really a big deal, either way...

Ken

Re: minor observations on Mac build of 22.0.99

[Richard Stallman]

    It's not apparent from what you quote, but you do know this refers to
    only a small number of files in the leim/quail directory, right?

No, I had forgotten about that.

Given that this is a special case, and not just a forgetful omission,
there is no need to change this.

Re: minor observations on Mac build of 22.0.99

[Glenn Morris]

Richard Stallman wrote:

>     Are these files in fact going to be identical aside from the date  
>     stamp in all builds?  If so, perhaps like the .elc files in the lisp  
>     tree they should be pre-generated for the release and pretest  
>     distributions.
>
> They definitely should be. I did not realize this was not already
> the case. Can someone please fix this and ack?

I see you added this to FOR-RELEASE.

i) There is no _need_ to do this before the release, is there?. No
problems have been reported to come from the present arrangement,
which has been in place for years, and all the pretests to date.

ii) Changing make-dist to add these .elc files (and the associated .el
files) is trivial (largely a matter of taking out the lines that
exclude these files), however:

iii) You will also need to change at least leim/Makefile.in. Doing
`make clean' in leim/ currently deletes the generated .el and .elc
files. So if you just add these files to the distribution without
changing leim/Makefile.in, `make clean' will remove some files that
were present in the distribution tarball. IMO it is on principal a
poor idea to make changes to the Makefiles shortly before a release
(if this is still true) when it is not necessary.