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

[Joe Buehler <jbuehler@hekimian.com>]

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