From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Joe Buehler Newsgroups: gmane.emacs.devel Subject: Re: [PATCHES] patches for compiling GNU emacs 21.2 under Cygwin Date: Tue, 03 Dec 2002 09:14:05 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: References: <7263-Wed27Nov2002204304+0200-eliz@is.elta.co.il> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1038924982 25256 80.91.224.249 (3 Dec 2002 14:16:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2002 14:16:22 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18JDqW-0006ZE-00 for ; Tue, 03 Dec 2002 15:16:20 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18JE03-0002NA-00 for ; Tue, 03 Dec 2002 15:26:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JDpR-0008B6-00; Tue, 03 Dec 2002 09:15:13 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18JDoV-0007pk-00 for emacs-devel@gnu.org; Tue, 03 Dec 2002 09:14:15 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18JDoS-0007oz-00 for emacs-devel@gnu.org; Tue, 03 Dec 2002 09:14:14 -0500 Original-Received: from main.gmane.org ([80.91.224.249]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JDoS-0007nQ-00 for emacs-devel@gnu.org; Tue, 03 Dec 2002 09:14:12 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18JDmA-0006Kj-00 for ; Tue, 03 Dec 2002 15:11:50 +0100 Original-To: emacs-devel@gnu.org X-Injected-Via-Gmane: http://gmane.org/ Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18JDm6-0006KN-00 for ; Tue, 03 Dec 2002 15:11:46 +0100 Original-Path: not-for-mail Original-Lines: 151 Original-NNTP-Posting-Host: 64.47.34.2 Original-X-Trace: main.gmane.org 1038924705 24308 64.47.34.2 (3 Dec 2002 14:11:45 GMT) Original-X-Complaints-To: usenet@main.gmane.org Original-NNTP-Posting-Date: Tue, 3 Dec 2002 14:11:45 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en In-Reply-To: <7263-Wed27Nov2002204304+0200-eliz@is.elta.co.il> Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9825 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9825 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