Re: [PATCH] nt/gmake,defs, nt/nmake.defs

Re: [PATCH] nt/gmake,defs, nt/nmake.defs

[Bill Meier]

Eli Zaretski wrote:
 > As I wrote earlier, I'd prefer that you use Emacs's copy-file
 > primitive to copy files.  That would certainly work on all supported
 > platforms, without requiring a cp that supports the -p option.
 > suspect that testing for the support of -p in a way that works on all
 > Windows shells would be a hard job anyway.

Sorry: I missed your original posting on this. I'll certainly look into 
using the Emacs copy-file primitive.

(For some reason, even though I'm subscribed to bug-gnu-emacs, I'm not 
receiving all the messages posted. I note that the gmane.org
archive (http://dir.gmane.org/gmane.emacs.bugs) isn't receiving all the 
postings either. Any idea what might be going on ?
For now, I'll monitor the list via the lists.gnu.org archive)

Bill Meier

Re: [PATCH] nt/gmake,defs, nt/nmake.defs

[Bill Meier]

Bill Meier wrote:
> 
> I note that the gmane.org
> archive (http://dir.gmane.org/gmane.emacs.bugs) isn't receiving all the 
> postings either. 

My mistake:: gmane.org *is* receiving all the postings. I must have some 
local EMail configuration problem....

Bill Meier

[PATCH] nt/gmake,defs, nt/nmake.defs

[Bill Meier]

I've just completed building emacs 22.1 on Windows using MinGW. Everything
went well. I note, however, that the install doesn't preserve the file
date/time/etc for the files copied to the install dirs (when the install dirs
are different than the build dirs). It seems to me that the date/time/etc
should be preserved.

The patch below (created using 'cvs diff') changes the definition of CP and
CP_DIR in the gmake.defs and nmake.defs files in nt/ to use the 'p' option.

Bill Meier


Index: nt/gmake.defs
===================================================================
RCS file: /sources/emacs/emacs/nt/gmake.defs,v
retrieving revision 1.33
diff -r1.33 gmake.defs
211,212c211,212
< CP		= cp -f
< CP_DIR		= cp -rf
---
> CP		= cp -pf
> CP_DIR		= cp -prf
Index: nt/nmake.defs
===================================================================
RCS file: /sources/emacs/emacs/nt/nmake.defs,v
retrieving revision 1.30
diff -r1.30 nmake.defs
159,160c159,160
< CP		= cp -f
< CP_DIR		= cp -rf
---
> CP		= cp -pf
> CP_DIR		= cp -prf

Re: [PATCH] nt/gmake,defs, nt/nmake.defs

[Eli Zaretskii]

> Date: Tue, 15 Jan 2008 17:18:45 -0500 (EST)
> From: Bill Meier <wmeier@newsguy.com>
> 
> The patch below (created using 'cvs diff') changes the definition of CP and
> CP_DIR in the gmake.defs and nmake.defs files in nt/ to use the 'p' option.

Thanks.

Unfortunately, I cannot accept this patch verbatim: I don't want us to
assume that `cp' supports the -p option.  (Some old versions don't.)
The fact that the user has GNU Make installed does not yet imply that
she has GNU cp.

If this is important to you, figure out how to test for the support of
the -p option in configure.bat, and then use the result of such a test
at "make install" time.  (If you want to work on this, please note
that the Windows build of Emacs still supports Windows 9x, so whatever
tests you invent must also work in COMMAND.COM, the default shell on
Windows 9x, not only with cmd.exe.)

Thanks again for working on this.

Re: [PATCH] nt/gmake,defs, nt/nmake.defs

[Bill Meier]

Eli Zaretskii <eliz <at> gnu.org> writes:

> If this is important to you, figure out how to test for the support of
> the -p option in configure.bat, and then use the result of such a test
> at "make install" time.  

OK.....

A question before I submit a revised patch:

Should I diff the patch against EMACS_22_BASE ?  MAIN (HEAD) ? or both ?

(Is it something like bug fixes to EMACS_22_BASE and enhancements to MAIN ?)

Thanks

Bill Meier

Re: [PATCH] nt/gmake,defs, nt/nmake.defs

[Eli Zaretskii]

> From: Bill Meier <wmeier@newsguy.com>
> Date: Fri, 18 Jan 2008 16:14:43 +0000 (UTC)
> 
> Should I diff the patch against EMACS_22_BASE ?  MAIN (HEAD) ? or both ?

It's better to diff against the EMACS_22_BASE branch: it will make
sure the change will be in the next release 22.2, and it will be
automatically merged into the trunk anyway.

> (Is it something like bug fixes to EMACS_22_BASE and enhancements to MAIN ?)

Yes, but yours is a bug report, not a request for enhancement.

But please do try to make your changes as isolated and unintrusive as
possible, because our reluctance to make dangerous changes in the
release branch.

Thanks for working on this.

Re: [PATCH] nt/gmake,defs, nt/nmake.defs

[Eli Zaretskii]

> Date: Fri, 18 Jan 2008 19:06:16 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: bug-gnu-emacs@gnu.org
> 
> But please do try to make your changes as isolated and unintrusive as
> possible, because our reluctance to make dangerous changes in the
> release branch.

Btw, one way to portably copy files at this stage is to use Emacs
itself, since the Emacs binary is already built at "make install"
time.  Emacs has a copy-file primitive that can preserve both time and
ownership information, like "cp -p" does.

Re: [PATCH] nt/gmake,defs, nt/nmake.defs

[Jason Rumney]

Eli Zaretskii wrote:
> Yes, but yours is a bug report, not a request for enhancement.
>   
Is it? I didn't see any report of problems caused by the file timestamp 
being the time of install.

Re: [PATCH] nt/gmake,defs, nt/nmake.defs

[Eli Zaretskii]

> Date: Fri, 18 Jan 2008 21:41:56 +0000
> From: Jason Rumney <jasonr@gnu.org>
> CC: Bill Meier <wmeier@newsguy.com>, bug-gnu-emacs@gnu.org
> 
> Eli Zaretskii wrote:
> > Yes, but yours is a bug report, not a request for enhancement.
> >   
> Is it? I didn't see any report of problems caused by the file timestamp 
> being the time of install.

Someone complained in the past that the current copying with "cp"
sometimes causes a warning from Emacs that a .el file is newer than
the corresponding .elc file.  We fixed that by copying *.elc files
first, then the *.el files, but that's a kludge, and it doesn't really
make sure that the warning will not come back on some very fast
filesystem.

Re: [PATCH] nt/gmake,defs, nt/nmake.defs

[Jason Rumney]

Eli Zaretskii wrote:
> Someone complained in the past that the current copying with "cp"
> sometimes causes a warning from Emacs that a .el file is newer than
> the corresponding .elc file.  We fixed that by copying *.elc files
> first, then the *.el files, but that's a kludge, and it doesn't really
> make sure that the warning will not come back on some very fast
> filesystem.
>   

I think you mean .el files first, then .elc files. But I don't think we 
will see filesystems that are faster than the speed of light anytime soon.

Re: [PATCH] nt/gmake,defs, nt/nmake.defs

[Bill Meier]

OK:

1. A Windows 'mingw32-make install' (to other than the build 
directories) ends up  installing files such as those in emacs/etc/ and 
such as the .el files without preserving the date/time of these (source) 
files. Although this may not cause any direct problems, IMHO it's a bug 
in the install.

I note from a a quick look at the *nix install scripts that the *nix 
install does preserve the file date/times (since tar .... is used to 
copy the files [at least for the .el files]).

(As an aside, I also note that the *nix install also removes any 
.cvsignore & etc files from the install destination directories as part 
of the install; I'll leave that to another time).

2. I'm happy to submit a proposed fix which will preserve the file 
date/times during an install (if cp implements -p).

I found after some further testing that my original fix did not work for 
all the files installed (specifically: the .el files) since the 
lisp/makefile.w32-in uses 'cp' (and not '$(CP)' for the install of the 
.el files & etc.


I'm inclined to do the fix as follows (comments welcome):

1. In lisp/makefile.w32-in:
For the install target: change 'cp -f' to '($CP)'

2. In configure.bat, gmake.defs and nmake.defs:
Add appropiate code so as to test for the availability of 'cp -p'  and 
to define CP (and CP_DIR) to include (or not) the '-p' option.


This approach changes all usage of CP and CP_DIR in the makefile.w32-in 
files to preserve file date/times; A review of the usage of $(CP) and 
some testing suggests this won't be a problem.

An alternative approach would be to change just the install usage of cp; 
  Eg: by defining a new macro (say) 'CPI=cp -p -f'   (if 'cp -p' 
implemented).

In this case the cp usage for install would need to be changed to use 
$(CPI) in some number of the various makefile.w32-in files.

Thoughts ?


Thanks

Bill Meier

Re: [PATCH] nt/gmake,defs, nt/nmake.defs

[Eli Zaretskii]

> Date: Sat, 19 Jan 2008 16:24:55 -0500
> From: Bill Meier <wmeier@newsguy.com>
> CC: Eli Zaretskii <eliz@gnu.org>, Jason Rumney <jasonr@gnu.org>
> 
> I'm inclined to do the fix as follows (comments welcome):
> 
> 1. In lisp/makefile.w32-in:
> For the install target: change 'cp -f' to '($CP)'
> 
> 2. In configure.bat, gmake.defs and nmake.defs:
> Add appropiate code so as to test for the availability of 'cp -p'  and 
> to define CP (and CP_DIR) to include (or not) the '-p' option.

As I wrote earlier, I'd prefer that you use Emacs's copy-file
primitive to copy files.  That would certainly work on all supported
platforms, without requiring a cp that supports the -p option.  I
suspect that testing for the support of -p in a way that works on all
Windows shells would be a hard job anyway.