Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Eli Zaretskii]

On Sun, 8 Dec 2002, Richard Stallman wrote:

> I don't recall seeing a message that answered the
> original question: is cygwin close enough to an existing system-type
> value that it would be simpler to use an existing value for it?

I hypothesized that cygwin is much closer to a Unix/GNU system than it is 
to windows-nt, and Joe Buehler confirmed that.  But some Windows aspects, 
such as case-insensitivity of the underlying file system, do need 
exceptions in Emacs code, and Joe took care of that by sending patches 
for Lisp packages.  (I hope to review those patches soon.)

> I have not read all the messages in this thread, since most of them
> seem to be about technicalities of Cygwin and Windows that I don't
> know anyway; perhaps some of them addressed that issue and I didn't
> notice they did.  Was that the case?  If so, I will find them and read
> them.

I think the above is the bottom line of the discussions of this aspect of 
the Cygwin port.  Joe, could you please confirm that?

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Joe Buehler]

Eli Zaretskii wrote:
> On Sun, 8 Dec 2002, Richard Stallman wrote:

>>I don't recall seeing a message that answered the
>>original question: is cygwin close enough to an existing system-type
>>value that it would be simpler to use an existing value for it?

> I hypothesized that cygwin is much closer to a Unix/GNU system than it is 
> to windows-nt, and Joe Buehler confirmed that.  But some Windows aspects, 
> such as case-insensitivity of the underlying file system, do need 
> exceptions in Emacs code, and Joe took care of that by sending patches 
> for Lisp packages.  (I hope to review those patches soon.)

> I think the above is the bottom line of the discussions of this aspect of 
> the Cygwin port.  Joe, could you please confirm that?

If I understand the question, yes, there are indeed parts of the .el files
where it is not appropriate to use either ms-dos or windows-nt as the system-type,
and there are places where it is.  For example, the Cygwin shells do not use
%VAR% to substitute environment variables.  On other other hand, Cygwin
runs on top of Windows, so filename case-insensitivity is the same as
for the windows ports.

Joe Buehler

[PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Joe Buehler]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

Attached are patches required to get emacs 21.2 up and running under Cygwin.

Some of the patches have already been submitted, and so are split into a separate
attachment.  I include them here for completeness, in case they never made it
into CVS yet.

Others are submitted here for the first time -- I have been waiting for my VP
to sign a copyright assignment for FSF.  I just got it and will get it in
the mail tomorrow.

Joe Buehler

[-- Attachment #2: cygwin-submitted-patches --]
[-- Type: application/x-java-applet, Size: 2206 bytes --]

[-- Attachment #3: cygwin-unsubmitted-patches --]
[-- Type: application/x-java-applet, Size: 13052 bytes --]

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Eli Zaretskii]

> From: Joe Buehler <jbuehler@hekimian.com>
> Date: Thu, 26 Sep 2002 15:10:30 -0400
> 
> Attached are patches required to get emacs 21.2 up and running under Cygwin.
> 
> Some of the patches have already been submitted, and so are split into a separate
> attachment.  I include them here for completeness, in case they never made it
> into CVS yet.
> 
> Others are submitted here for the first time -- I have been waiting for my VP
> to sign a copyright assignment for FSF.  I just got it and will get it in
> the mail tomorrow.

First, thank you for your contribution.  And sorry for such a long
delay in reviewing these patches.

Below are some comments based on reading the patches.  (I cannot
actually apply the patches and try using them, since I don't have the
Cygwin development enviroment installed.)

Please provide ChangeLog entries for each change.

Please also explain the changes the reason for which is not
self-evident.  For example, in this change to Makefile.in:

 -	   (cd $(docdir); chmod a+r DOC*; rm DOC); \
 +	   (cd ${docdir}; chmod a+r DOC*; if test "`echo DOC-*`" != "DOC-*"; \
 +		then rm DOC; fi); \

why is it necessary to add this test?  Is there something special in
the way the Cygwin port of Bash expands wildcards?

The purpose of this change is also not clear enough:

 +#ifdef CANNOT_DUMP
 +  FRAME_FOREGROUND_PIXEL(f) = FACE_TTY_DEFAULT_FG_COLOR;
 +  FRAME_BACKGROUND_PIXEL(f) = FACE_TTY_DEFAULT_BG_COLOR;
 +#endif

What is special about systems that cannot dump that requires this
fragment?

 -  (if (memq system-type '(hpux dgux usg-unix-v irix linux gnu/linux))
 +  (if (memq system-type '(hpux dgux usg-unix-v irix linux gnu/linux cygwin))

Since we are introducing a new value for system-type, it should be
documented in the ELisp manual, I think.

In this change:

 +#ifdef CYGWIN
 +#define _CYGWIN_EXE_SUFFIX .exe
 +#else
 +#define _CYGWIN_EXE_SUFFIX
 +#endif
 +
  install: ${archlibdir}
	 @echo
	 @echo "Installing utilities for users to run."
	 for file in ${INSTALLABLES} ; do \
	   $(INSTALL_PROGRAM) $(INSTALL_STRIP) $${file} ${bindir}/$${file} ; \
 -	  chmod a+rx ${bindir}/$${file}; \
 +	  chmod a+rx ${bindir}/$${file}_CYGWIN_EXE_SUFFIX; \
	 done
	 for file in ${INSTALLABLE_SCRIPTS} ; do \
	   $(INSTALL_PROGRAM) ${srcdir}/$${file} ${bindir}/$${file} ; \
	   chmod a+rx ${bindir}/$${file}; \
	 done

I don't really understand why is it necessary to introduce
_CYGWIN_EXE_SUFFIX.  On Windows, there's no need to run "chmod a+rx"
on *.exe programs.  If the issue is that there's no etags, say, but
etags.exe, and that chmod will print an error message if run on a
non-existent file, why not test if $$(file) exists and only run chmod
if it does?  Isn't that a simpler and cleaner solution?
 
 --- src/Makefile.in	2001-12-17 09:09:32.000000000 -0500
 +++ src/Makefile.in	2002-08-02 11:59:25.000000000 -0400
 @@ -836,7 +836,11 @@
  emacs: temacs ${etc}DOC ${lisp}
  #ifdef CANNOT_DUMP
	 rm -f emacs
 +#ifdef CYGWIN
 +	ln temacs.exe emacs
 +#else
	 ln temacs emacs
 +#endif

I think it's cleaner to introduce the EXE variable here, make it
empty on all platforms except Cygwin, and then use it everywhere,
instead of adding many #ifdef's.

 +/* let's not be adventurous */
 +#define SYSTEM_MALLOC 1

Why is that a good idea?  Isn't it better to use gmalloc and ralloc?
That should make an Emacs whose memory footprint does not grow that
much, I think.  What is so ``adventurous'' in using that?

Also, what about many "#ifdef WINDOWSNT" and "#ifdef DOS_NT" that we
have in the sources--are none of them appropriate for the Cygwin
build?  For example, what about setting system_eol_type (on coding.c)
to CODING_CR_LF?  Or about the part of editfns.c that gets the user
id from the enviroment variable USERNAME?  Or support for drive
letters in file names in fileio.c?  Isn't it better not to lose these
and other Windows-specific features?

I think Someone(tm) should also go through all the *.el files, look
for code that's specific to system-type windows-nt, and see which ones
should also work for system-type cygwin.

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Roman Belenov]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> I don't really understand why is it necessary to introduce
> _CYGWIN_EXE_SUFFIX.  On Windows, there's no need to run "chmod a+rx"
> on *.exe programs.

On cygwin, it makes sense - cygwin's default behaviour on Windows
NT and derivative systems is to map Windows permissions (including
"Read&Execute") to its own POSIX-like ones, so chmod command above is
not a no-op.

-- 
 							With regards, Roman.

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Eli Zaretskii]

On Thu, 28 Nov 2002, Roman Belenov wrote:

> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> 
> > I don't really understand why is it necessary to introduce
> > _CYGWIN_EXE_SUFFIX.  On Windows, there's no need to run "chmod a+rx"
> > on *.exe programs.
> 
> On cygwin, it makes sense - cygwin's default behaviour on Windows
> NT and derivative systems is to map Windows permissions (including
> "Read&Execute") to its own POSIX-like ones, so chmod command above is
> not a no-op.

Sorry, I don't understand; please elaborate.  Do you mean to say that 
Cygwin's port of GCC produces *.exe programs whose Execute bit is not 
set?  In other words, if I say "gcc hello.c -o hello.exe", do you mean to 
say that the produced hello.exe cannot be immediately invoked, without 
running chmod on it first?

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Roman Belenov]

Eli Zaretskii <eliz@is.elta.co.il> writes:

>> On cygwin, it makes sense - cygwin's default behaviour on Windows
>> NT and derivative systems is to map Windows permissions (including
>> "Read&Execute") to its own POSIX-like ones, so chmod command above is
>> not a no-op.
>
> Sorry, I don't understand; please elaborate.  Do you mean to say that 
> Cygwin's port of GCC produces *.exe programs whose Execute bit is not 
> set?  In other words, if I say "gcc hello.c -o hello.exe", do you mean to 
> say that the produced hello.exe cannot be immediately invoked, without 
> running chmod on it first?

It does; I wasn't sure that it could be invoked by any user, but
little experiment shows that it can be. Still not sure that it is
guaranteed in future versions of gcc and cygwin (BTW I couldn't find
anything on permissions of generated files in info files for gcc and
GNU ld).

-- 
 							With regards, Roman.

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Stefan Monnier]

> Also, what about many "#ifdef WINDOWSNT" and "#ifdef DOS_NT" that we
> have in the sources--are none of them appropriate for the Cygwin
> build?  For example, what about setting system_eol_type (on coding.c)
> to CODING_CR_LF?  Or about the part of editfns.c that gets the user
> id from the enviroment variable USERNAME?  Or support for drive
> letters in file names in fileio.c?  Isn't it better not to lose these
> and other Windows-specific features?
> 
> I think Someone(tm) should also go through all the *.el files, look
> for code that's specific to system-type windows-nt, and see which ones
> should also work for system-type cygwin.

I agree, but I think this is orthogonal: we can first install his patch
and then try and slowly merge the applicable parts of the NT and the
DOS code into the cygwin path.


	Stefan

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> Date: Mon, 02 Dec 2002 11:13:59 -0500
> 
> > I think Someone(tm) should also go through all the *.el files, look
> > for code that's specific to system-type windows-nt, and see which ones
> > should also work for system-type cygwin.
> 
> I agree, but I think this is orthogonal: we can first install his patch
> and then try and slowly merge the applicable parts of the NT and the
> DOS code into the cygwin path.

I don't disagree, but I do think that without sorting out
DOZe-specific code like I suggested, the Cygwin port might have some
subtle bugs and misfeatures.  So it can only be viewed as work in
progress, not something we could in good faith offer to users at
large.

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Stefan Monnier]

> > From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> > Date: Mon, 02 Dec 2002 11:13:59 -0500
> > 
> > > I think Someone(tm) should also go through all the *.el files, look
> > > for code that's specific to system-type windows-nt, and see which ones
> > > should also work for system-type cygwin.
> > 
> > I agree, but I think this is orthogonal: we can first install his patch
> > and then try and slowly merge the applicable parts of the NT and the
> > DOS code into the cygwin path.
> 
> I don't disagree, but I do think that without sorting out
> DOZe-specific code like I suggested, the Cygwin port might have some
> subtle bugs and misfeatures.  So it can only be viewed as work in
> progress, not something we could in good faith offer to users at
> large.

Yes, of course: we should only merge it in if we can be sure that there
will be someone maintaining and improving that version of the code.


	Stefan

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Jason Rumney]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> I don't disagree, but I do think that without sorting out
> DOZe-specific code like I suggested, the Cygwin port might have some
> subtle bugs and misfeatures.  So it can only be viewed as work in
> progress, not something we could in good faith offer to users at
> large.

My impression is that many of the misfeatures might be considered
features by those who would use the Cygwin port. Mostly they don't
want to interact with Windows programs in the Windows way. So it may
not be as much of a work in progress as it might seem.

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Eli Zaretskii]

On 2 Dec 2002, Jason Rumney wrote:

> My impression is that many of the misfeatures might be considered
> features by those who would use the Cygwin port.

This might indeed be so, but there's no way of knowing whether it's true 
without doing the footwork.

> Mostly they don't
> want to interact with Windows programs in the Windows way.

If this is accepted as the official policy of the Cygwin build, it should 
be at least documented.

Anyway, that's only one aspect of the issue; there are others.  For 
example, case-insensitivity in file names is something I'd expect Cygwin 
users to want Emacs to DTRT with.

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Joe Buehler]

Jason Rumney wrote:

> My impression is that many of the misfeatures might be considered
> features by those who would use the Cygwin port. Mostly they don't
> want to interact with Windows programs in the Windows way. So it may
> not be as much of a work in progress as it might seem.

As I wrote in another post just posted, this port is offered as part of
the official Cygwin application repository, and a number of people are
using it without any problems.  Cygwin is installed nowadays via
a setup.exe program that lets you select which applications you want to
install, and emacs 21.2 is one of them.

Joe Buehler

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Joe Buehler]

Eli Zaretskii wrote:

> Please provide ChangeLog entries for each change.

I'll check the web for instructions on how to do that.

> Please also explain the changes the reason for which is not
> self-evident.  For example, in this change to Makefile.in:
> 
>  -	   (cd $(docdir); chmod a+r DOC*; rm DOC); \
>  +	   (cd ${docdir}; chmod a+r DOC*; if test "`echo DOC-*`" != "DOC-*"; \
>  +		then rm DOC; fi); \
> 
> why is it necessary to add this test?  Is there something special in
> the way the Cygwin port of Bash expands wildcards?

There are bugs in emacs (both build/install and runtime) if you cannot
undump.  I assume that CANNOT_UNDUMP has not been tested in a while, since
the bugs should show up regardless of platform.

The above fix is because no DOC-* file is installed by "make install"
when CANNOT_UNDUMP.  Only a DOC file is, and that promptly gets removed
without the above patch.

> The purpose of this change is also not clear enough:
> 
>  +#ifdef CANNOT_DUMP
>  +  FRAME_FOREGROUND_PIXEL(f) = FACE_TTY_DEFAULT_FG_COLOR;
>  +  FRAME_BACKGROUND_PIXEL(f) = FACE_TTY_DEFAULT_BG_COLOR;
>  +#endif
> 
> What is special about systems that cannot dump that requires this
> fragment?

If you look at the code, you will see that there is no code path that
initializes the frame foreground and background pixels when CANNOT_UNDUMP
is in effect.  So you end up with black on black, which is of course
unreadable.  It took me a while to find this, but that's what is going on.

>  -  (if (memq system-type '(hpux dgux usg-unix-v irix linux gnu/linux))
>  +  (if (memq system-type '(hpux dgux usg-unix-v irix linux gnu/linux cygwin))
> 
> Since we are introducing a new value for system-type, it should be
> documented in the ELisp manual, I think.

Are you asking for a patch from me or is this a note to others who work
on that?

> In this change:
> 
>  +#ifdef CYGWIN
>  +#define _CYGWIN_EXE_SUFFIX .exe
>  +#else
>  +#define _CYGWIN_EXE_SUFFIX
>  +#endif
>  +
>   install: ${archlibdir}
> 	 @echo
> 	 @echo "Installing utilities for users to run."
> 	 for file in ${INSTALLABLES} ; do \
> 	   $(INSTALL_PROGRAM) $(INSTALL_STRIP) $${file} ${bindir}/$${file} ; \
>  -	  chmod a+rx ${bindir}/$${file}; \
>  +	  chmod a+rx ${bindir}/$${file}_CYGWIN_EXE_SUFFIX; \
> 	 done
> 	 for file in ${INSTALLABLE_SCRIPTS} ; do \
> 	   $(INSTALL_PROGRAM) ${srcdir}/$${file} ${bindir}/$${file} ; \
> 	   chmod a+rx ${bindir}/$${file}; \
> 	 done
> 
> I don't really understand why is it necessary to introduce
> _CYGWIN_EXE_SUFFIX.  On Windows, there's no need to run "chmod a+rx"
> on *.exe programs.  If the issue is that there's no etags, say, but
> etags.exe, and that chmod will print an error message if run on a
> non-existent file, why not test if $$(file) exists and only run chmod
> if it does?  Isn't that a simpler and cleaner solution?

Whatever solution you like is fine with me -- the problem is that the
file does need execute permission, and it is not being created with it.
Cygwin maps between Windows ACLs and UNIX permissions bits -- the chmod
command actually does do something useful here -- it is changing Windows
permissions to settings that are seen as "a+rx" under Cygwin.

The .exe suffix is necessary because binaries on Win9x machines require
the suffix to run -- the Cygwin port of emacs does indeed run non-X11
or X11 under Windows 9x!

>  --- src/Makefile.in	2001-12-17 09:09:32.000000000 -0500
>  +++ src/Makefile.in	2002-08-02 11:59:25.000000000 -0400
>  @@ -836,7 +836,11 @@
>   emacs: temacs ${etc}DOC ${lisp}
>   #ifdef CANNOT_DUMP
> 	 rm -f emacs
>  +#ifdef CYGWIN
>  +	ln temacs.exe emacs
>  +#else
> 	 ln temacs emacs
>  +#endif
> 
> I think it's cleaner to introduce the EXE variable here, make it
> empty on all platforms except Cygwin, and then use it everywhere,
> instead of adding many #ifdef's.

Whatever you want to do, go for it.  I submitted the patches with
the expectation that they would provide the information necessary to
get an official Cygwin port.  I don't care how they are changed to
conform to the official way of doing things.

>  +/* let's not be adventurous */
>  +#define SYSTEM_MALLOC 1
> 
> Why is that a good idea?  Isn't it better to use gmalloc and ralloc?
> That should make an Emacs whose memory footprint does not grow that
> much, I think.  What is so ``adventurous'' in using that?

Cygwin has its complexities in the area of memory usage.  I did not
use emacs malloc to avoid one more source of headaches -- it was unclear
at the beginning that I would ever get the thing to work, because Cygwin's
fork() is very sensitive to where things reside in memory.  I will try
it now that there is a stable emacs Cygwin port, and let you know what happens.

> Also, what about many "#ifdef WINDOWSNT" and "#ifdef DOS_NT" that we
> have in the sources--are none of them appropriate for the Cygwin
> build?  For example, what about setting system_eol_type (on coding.c)
> to CODING_CR_LF?  Or about the part of editfns.c that gets the user
> id from the enviroment variable USERNAME?  Or support for drive
> letters in file names in fileio.c?  Isn't it better not to lose these
> and other Windows-specific features?

Drive letters in file names is one thing that is currently missing that
would be really nice to have.  The problem is one of time -- it would take
time to run through all the DOS and Windows #ifdefs, and I have already
spent a lot of my company's time on this port.  And -- I have what I need
for the moment -- an X11 emacs that runs on remote NT machines in the
Cygwin environment.  The #ifdefs cannot be turned on and expected to just work,
because Cygwin is more like a UNIX environment than a Windows environment,
and all sorts of things will break or just do the wrong thing.

> I think Someone(tm) should also go through all the *.el files, look
> for code that's specific to system-type windows-nt, and see which ones
> should also work for system-type cygwin.

I think I looked for system-type things when the chown problems were fixed,
but I will look again.

By the way, it may not be clear, but this emace port is currently an official
Cygwin package that is part of their download setup, and a number of people
are using it.  It may not be perfect in the eyes of the emacs hackers,
but there haven't been any bugs reported in the last couple months.

Joe Buehler

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Joe Buehler]

>  +/* let's not be adventurous */
>  +#define SYSTEM_MALLOC 1
>
> Why is that a good idea?  Isn't it better to use gmalloc and ralloc?
> That should make an Emacs whose memory footprint does not grow that
> much, I think.  What is so ``adventurous'' in using that?

I recompiled emacs 21.2 under Cygwin without SYSTEM_MALLOC, and it appears
to work just fine.  Under Windows NT, at least -- I'll let you know
if the released version gets complaints from users of other versions
of Windows.

Joe Buehler

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Eli Zaretskii]

> From: Joe Buehler <jbuehler@hekimian.com>
> Date: Tue, 03 Dec 2002 11:37:40 -0500
> 
> I recompiled emacs 21.2 under Cygwin without SYSTEM_MALLOC, and it appears
> to work just fine.  Under Windows NT, at least -- I'll let you know
> if the released version gets complaints from users of other versions
> of Windows.

Thank you!

It might be a good idea to try to track the memory footprint of an
Emacs compiled with and without SYSTEM_MALLOC (assuming that the
sessions are running long enough).

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Eli Zaretskii]

> From: Joe Buehler <jbuehler@hekimian.com>
> Date: Tue, 03 Dec 2002 09:14:05 -0500
> 
> > Please provide ChangeLog entries for each change.
> 
> I'll check the web for instructions on how to do that.

A better place to look for the instructions is in standards.texi.  It
is distributed with a couple of GNU packages, so it might already be
installed on your system; try "info standards" from the shell prompt.
If not, you can download it from the GNU ftp site.

> >  -	   (cd $(docdir); chmod a+r DOC*; rm DOC); \
> >  +	   (cd ${docdir}; chmod a+r DOC*; if test "`echo DOC-*`" != "DOC-*"; \
> >  +		then rm DOC; fi); \
> > 
> > why is it necessary to add this test?  Is there something special in
> > the way the Cygwin port of Bash expands wildcards?
> 
> There are bugs in emacs (both build/install and runtime) if you cannot
> undump.  I assume that CANNOT_UNDUMP has not been tested in a while, since
> the bugs should show up regardless of platform.
> 
> The above fix is because no DOC-* file is installed by "make install"
> when CANNOT_UNDUMP.

Well, then perhaps the right thing to do is to fix "make install" so
that it installs DOC-* for the systems that CANNOT_UNDUMP?

> >  +#ifdef CANNOT_DUMP
> >  +  FRAME_FOREGROUND_PIXEL(f) = FACE_TTY_DEFAULT_FG_COLOR;
> >  +  FRAME_BACKGROUND_PIXEL(f) = FACE_TTY_DEFAULT_BG_COLOR;
> >  +#endif
> > 
> > What is special about systems that cannot dump that requires this
> > fragment?
> 
> If you look at the code, you will see that there is no code path that
> initializes the frame foreground and background pixels when CANNOT_UNDUMP
> is in effect.

I see such code in dispnew.c:init_display.  It looks like it should
run for all the systems, or did I miss something?  (Sorry, I don't
have access to a system that cannot undump, so I cannot check this
myself.)

> > Since we are introducing a new value for system-type, it should be
> > documented in the ELisp manual, I think.
> 
> Are you asking for a patch from me or is this a note to others who work
> on that?

I don't know if anyone else is working on Cygwin support.  It would be
nice if you could provide the necessary patch for the docs.  The file
etc/NEWS should also say that a Cygwin build is now supported.

> Whatever solution you like is fine with me -- the problem is that the
> file does need execute permission, and it is not being created with it.

Really?  I already asked someone in this thread about this: does
Cygwin GCC really produce foo.exe programs that aren't
world-executable?  That person checked and came back saying that chmod
wasn't necessary.

> Cygwin maps between Windows ACLs and UNIX permissions bits -- the chmod
> command actually does do something useful here -- it is changing Windows
> permissions to settings that are seen as "a+rx" under Cygwin.

Let me understand this: are you saying that if a user Bob builds
hello.exe with the Cygwin port of GCC and installs it in a public
directory, then a user Alice on the same machine cannot run this
hello.exe?  I'd be surprised if this was the case, as it would confuse
every Windows user out there.

> The .exe suffix is necessary because binaries on Win9x machines require
> the suffix to run

Sorry, I don't understand: are you saying that to run foo.exe you need
to say ``system("foo.exe")'', and that ``system("foo")'' will not
work under Cygwin?

> >  --- src/Makefile.in	2001-12-17 09:09:32.000000000 -0500
> >  +++ src/Makefile.in	2002-08-02 11:59:25.000000000 -0400
> >  @@ -836,7 +836,11 @@
> >   emacs: temacs ${etc}DOC ${lisp}
> >   #ifdef CANNOT_DUMP
> > 	 rm -f emacs
> >  +#ifdef CYGWIN
> >  +	ln temacs.exe emacs
> >  +#else
> > 	 ln temacs emacs
> >  +#endif
> > 
> > I think it's cleaner to introduce the EXE variable here, make it
> > empty on all platforms except Cygwin, and then use it everywhere,
> > instead of adding many #ifdef's.
> 
> Whatever you want to do, go for it.  I submitted the patches with
> the expectation that they would provide the information necessary to
> get an official Cygwin port.  I don't care how they are changed to
> conform to the official way of doing things.

I thought you were offering to do a complete job of making Cygwin
patches.  I don't know who else will be willing or able to work on
this; I certainly cannot.

My comments were written under an assumption that you'd be willing to
rework your changes to take care of the issues I raise, unless you
disagree with what I suggest.  Sorry if I misunderstood.

> The #ifdefs cannot be turned on and expected to just work,
> because Cygwin is more like a UNIX environment than a Windows environment,
> and all sorts of things will break or just do the wrong thing.

Sure, I know this.  That's why I think someone should review those
#ifdef's and decide what to do with each one of them.

> By the way, it may not be clear, but this emace port is currently an official
> Cygwin package that is part of their download setup, and a number of people
> are using it.  It may not be perfect in the eyes of the emacs hackers,
> but there haven't been any bugs reported in the last couple months.

That's good to hear.  However, Emacs is a very large package, and so
it would take a lot of testing to make sure that a large portion of
optional *.el files does TRT in the Cygwin build.  Some rarely used
packages might never get any testing until some user who needs just
that package bumps into a bug.

So I think manual inspection of the Lisp code which mentions
windows-nt is something that should be done, ideally before the Cygwin
patches are installed in the CVS, or at least before the current
development version goes into pretest.

Once again, thanks for working on this.

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Roman Belenov]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> Really?  I already asked someone in this thread about this: does
> Cygwin GCC really produce foo.exe programs that aren't
> world-executable?  That person checked and came back saying that chmod
> wasn't necessary.

I learned more about the situation. Actually, cygwin has a concept of
umask, so that permissions of created files depend on user's
settings. On my system umask was 0, so that produced executables were
world-executable, but this can be easily changed.

> Let me understand this: are you saying that if a user Bob builds
> hello.exe with the Cygwin port of GCC and installs it in a public
> directory, then a user Alice on the same machine cannot run this
> hello.exe?  I'd be surprised if this was the case, as it would confuse
> every Windows user out there.

I user Bob had "umask 700" in his ~/.profile, it would be the case.

-- 
 							With regards, Roman.

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Kim F. Storm]

Joe Buehler <jbuehler@hekimian.com> writes:

> Eli Zaretskii wrote:
> 
> > Please provide ChangeLog entries for each change.
> 
> I'll check the web for instructions on how to do that.
> 
> > Please also explain the changes the reason for which is not
> > self-evident.  For example, in this change to Makefile.in:
> >  -	   (cd $(docdir); chmod a+r DOC*; rm DOC); \
> >  +	   (cd ${docdir}; chmod a+r DOC*; if test "`echo DOC-*`" != "DOC-*"; \
> >  +		then rm DOC; fi); \
> > why is it necessary to add this test?  Is there something special in
> > the way the Cygwin port of Bash expands wildcards?
> 
> There are bugs in emacs (both build/install and runtime) if you cannot
> undump.  I assume that CANNOT_UNDUMP has not been tested in a while, since
> the bugs should show up regardless of platform.
> 
> The above fix is because no DOC-* file is installed by "make install"
> when CANNOT_UNDUMP.  Only a DOC file is, and that promptly gets removed
> without the above patch.

I installed this fix on HEAD back in August.

> 
> > The purpose of this change is also not clear enough:
> >  +#ifdef CANNOT_DUMP
> >  +  FRAME_FOREGROUND_PIXEL(f) = FACE_TTY_DEFAULT_FG_COLOR;
> >  +  FRAME_BACKGROUND_PIXEL(f) = FACE_TTY_DEFAULT_BG_COLOR;
> >  +#endif
> > What is special about systems that cannot dump that requires this
> > fragment?
> 
> If you look at the code, you will see that there is no code path that
> initializes the frame foreground and background pixels when CANNOT_UNDUMP
> is in effect.  So you end up with black on black, which is of course
> unreadable.  It took me a while to find this, but that's what is going on.

I installed this fix on HEAD back in August, too.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Richard Stallman]

The instructions for writing change logs are in the 
GNU coding standards.  See www.gnu.org/prep/standards.*.

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Richard Stallman]

    >  -  (if (memq system-type '(hpux dgux usg-unix-v irix linux gnu/linux))
    >  +  (if (memq system-type '(hpux dgux usg-unix-v irix linux gnu/linux cygwin))
    > 
    > Since we are introducing a new value for system-type, it should be
    > documented in the ELisp manual, I think.

Making a new value for system-type is a drastic thing to do.
It could mean many places that test system-type need to be changed.
Is that really the best thing to do here?  How many of these tests
want to treat cygwin differently from windows-nt, and how many of
them want to treat it the same?

Is it possible to distinguish them using system-configuration?

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Eli Zaretskii]

On Wed, 4 Dec 2002, Richard Stallman wrote:

> Making a new value for system-type is a drastic thing to do.
> It could mean many places that test system-type need to be changed.
> Is that really the best thing to do here?  How many of these tests
> want to treat cygwin differently from windows-nt, and how many of
> them want to treat it the same?

Actually, I'd expect the Cygwin build be very close to the Unix and GNU 
systems, not to windows-nt.  But there are, at least in principle, cases 
where they will need to do something Windowsish, like with 
case-sensitivity in file names.

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Joe Buehler]

Eli Zaretskii wrote:

> Actually, I'd expect the Cygwin build be very close to the Unix and GNU 
> systems, not to windows-nt.  But there are, at least in principle, cases 
> where they will need to do something Windowsish, like with 
> case-sensitivity in file names.

I just went through all uses of system-type, and that's exactly right.
The windows-nt system-type is being used to mean all sorts of things,
such as "be case-insensitive for file names" and some of them apply to
Cygwin, but many do not, because the programming API is that of UNIX.

Joe Buehler

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Eli Zaretskii]

On Wed, 4 Dec 2002, Joe Buehler wrote:

> The windows-nt system-type is being used to mean all sorts of things,
> such as "be case-insensitive for file names" and some of them apply to
> Cygwin, but many do not, because the programming API is that of UNIX.

One idea would be to factor the various issues and provide predicates for 
each one of them, like what we did with display-*-p vs window-system.  
Then we could have something like system-case-insensitive-filenames-p and 
the likes, and we could eliminate many of the system-type tests.  The 
need for introducing yet another system-type value will then become a
moot point.

But that's a substantial job, so someone will need to step forward and 
volunteer.  (I can't do it due to total lack of free time, sorry.)

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Richard Stallman]

    Then we could have something like system-case-insensitive-filenames-p and 
    the likes, and we could eliminate many of the system-type tests.

I think this is more trouble than it is worth.  It would merely
improve the elegance of the system internals; it would do nothing
for the user.

We have many tasks waiting to be done that would make Emacs better to
edit with.  I think it would be a shame for a job like this to take
away scarce volunteer energy from that.

Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 06 Dec 2002 08:31:57 -0500
> 
>     Then we could have something like system-case-insensitive-filenames-p and 
>     the likes, and we could eliminate many of the system-type tests.
> 
> I think this is more trouble than it is worth.  It would merely
> improve the elegance of the system internals; it would do nothing
> for the user.

It would prevent us from introducing yet another value of system-type,
which is something I thought you wanted to avoid.  I posted my
suggestion in response to your concern.