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

[Eli Zaretskii]

> From: Joe Buehler <address@hidden>
> 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.