CVS Emacs cygwin build problem.

CVS Emacs cygwin build problem.

[Steven Wu]

If building CVS Emacs on cygwin platform, a problem may occur, and  
the message looks like:

===
make[1]: Entering directory `/cygdrive/c/dev/emacs-src/emacs/lisp'
/cygdrive/c/dev/emacs-src/emacs/lisp/../update-subdirs /cygdrive/c/ 
dev/emacs-src/emacs/lisp; \
for file in calc calendar emacs-lisp emulation eshell gnus  
international language mail mh-e net obsolete play progmodes term  
textmodes toolbar url; do \
/cygdrive/c/dev/emacs-src/emacs/lisp/../update-subdirs $file; \
done;
Directories: calc calendar emacs-lisp emulation eshell gnus  
international language mail mh-e net obsolete play progmodes
term textmodes toolbar url
"./../bin/emacs.exe" -batch --no-init-file --no-site-file --multibyte  
-l autoload \
--eval '(setq find-file-hook nil \
find-file-suppress-same-file-warnings t \
generated-autoload-file \
"/cygdrive/c/dev/emacs-src/emacs/lisp/loaddefs.el")' \
-f batch-update-autoloads /cygdrive/c/dev/emacs-src/emacs/lisp calc  
calendar emacs-lisp emulation eshell gnus in
ternational language mail mh-e net obsolete play progmodes term  
textmodes toolbar url
Cannot open load file: encoded-kb
Signal 127
make[1]: *** [autoloads] Error 255
make[1]: Leaving directory `/cygdrive/c/dev/emacs-src/emacs/lisp'
===

This only happens to cygwin, but not MinGW or Visual Studio build.  
The problem is that the default make mode for make 3.80, which comes  
with the std cygwin distribution, is Unix mode. Hence, the paths of  
directories and files known to make are in Unix form.  During the  
compilation of c code, there is no problem because cygwin gcc  
understand cygwin path. However when bootstrapping the elisp files,  
things are different.

In the emacs/lisp/makefile.w32-in, line 30

lisp = $(CURDIR)

here lisp is set to the current directory. For nmake, or minGW make,  
this $(CURDIR) is window path. For cygwin, this is cygwin unix-like  
path. Because Emacs isn't compiled with cygwin libraries, Emacs  
doesn't understand cygwin path, and hence it cannot load the encoded-kb.

The fix for this is to change lisp=$(shell cygpath -m $(CURDIR)).  
Condition like the cygwin test can be added to guard this.

Similar changes is also needed for leim directory.

steve

Re: CVS Emacs cygwin build problem.

[Jason Rumney]

Steven Wu wrote:
> If building CVS Emacs on cygwin platform, a problem may occur, and the 
> message looks like:
> ....
> In the emacs/lisp/makefile.w32-in, line 30

When building on the Cygwin platform, you should not be using the 
Windows specific configure script and makefiles.

CVS Emacs cygwin build problem.

[djh]

Steven,
  which cygwin version are you talking about.  cygwin made some substantial changes between 5.18 and 5.19.  cvs builds on cygwin 5.18 as of a week ago.  I had trouble with 5.19 and not enough time to debug the problems.  

  The version of cygwin you're using makes a difference so please include that infomration.


Darel Henman

Re: CVS Emacs cygwin build problem.

[Eli Zaretskii]

> Date: Thu, 18 May 2006 23:47:37 -0700
> From: "Steven Wu" <wus@qwest.net>
> 
> Cannot open load file: encoded-kb
> Signal 127
> make[1]: *** [autoloads] Error 255
> make[1]: Leaving directory `/cygdrive/c/dev/emacs-src/emacs/lisp'
> ===
> 
> This only happens to cygwin, but not MinGW or Visual Studio build.  
> The problem is that the default make mode for make 3.80, which comes  
> with the std cygwin distribution, is Unix mode. Hence, the paths of  
> directories and files known to make are in Unix form.  During the  
> compilation of c code, there is no problem because cygwin gcc  
> understand cygwin path. However when bootstrapping the elisp files,  
> things are different.
> 
> In the emacs/lisp/makefile.w32-in, line 30
> 
> lisp = $(CURDIR)
> 
> here lisp is set to the current directory. For nmake, or minGW make,  
> this $(CURDIR) is window path. For cygwin, this is cygwin unix-like  
> path. Because Emacs isn't compiled with cygwin libraries, Emacs  
> doesn't understand cygwin path, and hence it cannot load the encoded-kb.

Sorry, I'm confused: are you building a Cygwin version of Emacs, or a
native Windows version?  If the former, you should configure and build
Emacs as on Unix: type "./configure" and then "make" in the top-level
directory.  Only if you are building a native Windows port of Emacs
should you chdir to the `nt' directory and use configure.bat from
there followed by a "make" command from that directory.  In the latter
case, you should not use the Cygwin make: the file nt/INSTALL clearly
indicates that doing so fails precisely due to the problem you saw:
the incompatible /cygdrive/c/foo syntax of file names.

Re: CVS Emacs cygwin build problem.

[Steven Wu]

On May 19, 2006, at 4:33 AM, Eli Zaretskii wrote:

>> Date: Thu, 18 May 2006 23:47:37 -0700
>> From: "Steven Wu" <wus@qwest.net>
>>
>> Cannot open load file: encoded-kb
>> Signal 127
>> make[1]: *** [autoloads] Error 255
>> make[1]: Leaving directory `/cygdrive/c/dev/emacs-src/emacs/lisp'
>> ===
>>
>> This only happens to cygwin, but not MinGW or Visual Studio build.
>> The problem is that the default make mode for make 3.80, which comes
>> with the std cygwin distribution, is Unix mode. Hence, the paths of
>> directories and files known to make are in Unix form.  During the
>> compilation of c code, there is no problem because cygwin gcc
>> understand cygwin path. However when bootstrapping the elisp files,
>> things are different.
>>
>> In the emacs/lisp/makefile.w32-in, line 30
>>
>> lisp = $(CURDIR)
>>
>> here lisp is set to the current directory. For nmake, or minGW make,
>> this $(CURDIR) is window path. For cygwin, this is cygwin unix-like
>> path. Because Emacs isn't compiled with cygwin libraries, Emacs
>> doesn't understand cygwin path, and hence it cannot load the  
>> encoded-kb.
>
> Sorry, I'm confused: are you building a Cygwin version of Emacs, or a
> native Windows version?  If the former, you should configure and build
> Emacs as on Unix: type "./configure" and then "make" in the top-level
> directory.  Only if you are building a native Windows port of Emacs
> should you chdir to the `nt' directory and use configure.bat from
> there followed by a "make" command from that directory.  In the latter
> case, you should not use the Cygwin make: the file nt/INSTALL clearly
> indicates that doing so fails precisely due to the problem you saw:
> the incompatible /cygdrive/c/foo syntax of file names.
>
Currently the configure.bat allows --with-gcc, when under cygwin, it  
correctly uses -mno-cygwin flag. This option allows Emacs to be built  
window native with cygwin development environment. I have done it  
with the fixed I mentioned. It works fine.

steve

Re: CVS Emacs cygwin build problem.

[Steven Wu]

On May 19, 2006, at 1:17 AM, Jason Rumney wrote:

> Steven Wu wrote:
>> If building CVS Emacs on cygwin platform, a problem may occur, and  
>> the message looks like:
>> ....
>> In the emacs/lisp/makefile.w32-in, line 30
>
> When building on the Cygwin platform, you should not be using the  
> Windows specific configure script and makefiles.
>
>
Window native Emacs can be built using gcc from cygwin, and I am  
currently running it without problem.

RE: CVS Emacs cygwin build problem.

[Steven Wu]

Darel,

the cygwin I have is the latest version which is 5.19. After the fix,  
I had built and run native Emacs with cygwin gcc without problem.

steve

Re: CVS Emacs cygwin build problem.

[Eli Zaretskii]

> Date: Fri, 19 May 2006 07:06:39 -0700
> From: "Steven Wu" <wus@qwest.net>
> Cc: emacs-devel@gnu.org
> 
> Currently the configure.bat allows --with-gcc, when under cygwin, it  
> correctly uses -mno-cygwin flag. This option allows Emacs to be built  
> window native with cygwin development environment.

Okay, so you are building the native Windows port.  In that case, all
you need to do is use make.exe that is not a Cygwin port (get one from
MinGW or build it yourself from the official FSF sources with the
"-mno-cygwin" switch).  Possibly, also remove the Cygwin sh.exe from
PATH (the build procedure will then use cmd.exe).  This should fix
your problems, as nt/INSTALL indicates.

Re: CVS Emacs cygwin build problem.

[Steven Wu]

On May 19, 2006, at 8:28 AM, Eli Zaretskii wrote:

>> Date: Fri, 19 May 2006 07:06:39 -0700
>> From: "Steven Wu" <wus@qwest.net>
>> Cc: emacs-devel@gnu.org
>>
>> Currently the configure.bat allows --with-gcc, when under cygwin, it
>> correctly uses -mno-cygwin flag. This option allows Emacs to be built
>> window native with cygwin development environment.
>
> Okay, so you are building the native Windows port.  In that case, all
> you need to do is use make.exe that is not a Cygwin port (get one from
> MinGW or build it yourself from the official FSF sources with the
> "-mno-cygwin" switch).  Possibly, also remove the Cygwin sh.exe from
> PATH (the build procedure will then use cmd.exe).  This should fix
> your problems, as nt/INSTALL indicates.
>
I guess the advantage of my approach is that we don't need anything  
else. Cygwin make.exe builds the Emacs fine, except for that little  
thing. A simple condition can fix all the problems related to this.

steve

Re: CVS Emacs cygwin build problem.

[Jason Rumney]

"Steven Wu" <wus@qwest.net> writes:

> I guess the advantage of my approach is that we don't need anything
> else. Cygwin make.exe builds the Emacs fine, except for that little
> thing. A simple condition can fix all the problems related to this.

That "simple condition" is an ugly hack that most likely breaks the
build for other versions of make.

Re: CVS Emacs cygwin build problem.

[Steven Wu]

On May 20, 2006, at 12:45 AM, Jason Rumney wrote:

> "Steven Wu" <wus@qwest.net> writes:
>
>> I guess the advantage of my approach is that we don't need anything
>> else. Cygwin make.exe builds the Emacs fine, except for that little
>> thing. A simple condition can fix all the problems related to this.
>
> That "simple condition" is an ugly hack that most likely breaks the
> build for other versions of make.
>
>

it doesn't have to. Simply check the existence of CYGWIN environment  
variable, and if it is set,

ifdef CYGWIN
lisp = $(shell cygpath -m $(CURDIR))
else
lisp = $(CURDIR)
endif

See this is need only in the makefile.w32-in. For those who compile  
window native Emacs using cygwin utils, this change can only help  
them, and it won't affect minGW. For those compile Emacs under  
cygwin, they don't use makefile.w32-in. I don't see what other system  
will be affected except maybe nmake.

Re: CVS Emacs cygwin build problem.

[Jason Rumney]

"Steven Wu" <wus@qwest.net> writes:

> ifdef CYGWIN
> lisp = $(shell cygpath -m $(CURDIR))
> else
> lisp = $(CURDIR)
> endif
>
> See this is need only in the makefile.w32-in. For those who compile
> window native Emacs using cygwin utils, this change can only help
> them, and it won't affect minGW. For those compile Emacs under
> cygwin, they don't use makefile.w32-in. I don't see what other system
> will be affected except maybe nmake.

Our previous experience is that it does affect mingw make, when run
under Cygwin bash.

Re: CVS Emacs cygwin build problem.

[Eli Zaretskii]

> Date: Fri, 19 May 2006 20:48:22 -0700
> From: "Steven Wu" <wus@qwest.net>
> Cc: emacs-devel@gnu.org
> 
> I guess the advantage of my approach is that we don't need anything  
> else. Cygwin make.exe builds the Emacs fine, except for that little  
> thing.

Maybe today all you need is to change those two files.  Tomorrow, the
same problem could happen in other places as well, even if we find
some ingenious way of working around the real problems in your
suggestion, as pointed out by Jason.

The upshot of all this discussion is that there's a fundamental
incompatibility between the Cygwin Make and the native Windows build
of Emacs.  It's not good engineering to apply band-aids for such
fundamental problems; instead, one should go ahead and solve the
incompatibility itself.

In practical terms, this means either (a) use a native port of GNU
Make, e.g. one that is built with -mno-cygwin, or (b) lobby the Cygwin
developers to provide a special switch to the Cygwin Make which would
cause it to use native Windows d:/foo/bar file-name syntax.

Re: CVS Emacs cygwin build problem.

[Steven Wu]

On May 20, 2006, at 2:03 AM, Eli Zaretskii wrote:

>> Date: Fri, 19 May 2006 20:48:22 -0700
>> From: "Steven Wu" <wus@qwest.net>
>> Cc: emacs-devel@gnu.org
>>
>> I guess the advantage of my approach is that we don't need anything
>> else. Cygwin make.exe builds the Emacs fine, except for that little
>> thing.
>
> Maybe today all you need is to change those two files.  Tomorrow, the
> same problem could happen in other places as well, even if we find
> some ingenious way of working around the real problems in your
> suggestion, as pointed out by Jason.
>
> The upshot of all this discussion is that there's a fundamental
> incompatibility between the Cygwin Make and the native Windows build
> of Emacs.  It's not good engineering to apply band-aids for such
> fundamental problems; instead, one should go ahead and solve the
> incompatibility itself.
>
> In practical terms, this means either (a) use a native port of GNU
> Make, e.g. one that is built with -mno-cygwin, or (b) lobby the Cygwin
> developers to provide a special switch to the Cygwin Make which would
> cause it to use native Windows d:/foo/bar file-name syntax.
>

Actually, cygwin make has --win32 switch which tells the make to use  
windows path and etc. I can experiment a little bit and see if there  
is other problem. If that works, the only change will be in nt/ 
INSTALL file to tell people to use that option.

steve

Re: CVS Emacs cygwin build problem.

[Eli Zaretskii]

> Date: Sat, 20 May 2006 06:36:02 -0700
> From: "Steven Wu" <wus@qwest.net>
> Cc: emacs-devel@gnu.org
> 
> Actually, cygwin make has --win32 switch which tells the make to use  
> windows path and etc. I can experiment a little bit and see if there  
> is other problem.

Please do.  If the --win32 switch does the trick, it would be a good
solution.

Re: CVS Emacs cygwin build problem.

[Richard Stallman]

    > Actually, cygwin make has --win32 switch which tells the make to use  
    > windows path and etc. I can experiment a little bit and see if there  
    > is other problem.

How can I reach the maintainer of Cygwin make?  It is not a good thing
for an option related to Windows to be called "win" something.

Re: CVS Emacs cygwin build problem.

[Steven Wu]

On May 20, 2006, at 5:56 PM, Richard Stallman wrote:

>> Actually, cygwin make has --win32 switch which tells the make to use
>> windows path and etc. I can experiment a little bit and see if there
>> is other problem.
>
> How can I reach the maintainer of Cygwin make?  It is not a good thing
> for an option related to Windows to be called "win" something.
>

I am not sure who is the maintainer of cygwin make, however, make -- 
win32 is in the current cygwin make. There is also a --unix switch I  
believe. The other way is to set MAKE_MODE=win|unix, and run make.

Re: CVS Emacs cygwin build problem.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: wus@qwest.net, emacs-devel@gnu.org
> Date: Sat, 20 May 2006 20:56:21 -0400
> 
>     > Actually, cygwin make has --win32 switch which tells the make to use  
>     > windows path and etc. I can experiment a little bit and see if there  
>     > is other problem.
> 
> How can I reach the maintainer of Cygwin make?  It is not a good thing
> for an option related to Windows to be called "win" something.

"Win32" is the proper name of MS-Windows API; I believe this is the
reason for the name of the option.

I don't know who maintains the Cygwin Make, but Chris Faylor
<cgf@alum.bu.edu> or <cgf@timesys.com> is one of the main Cygwin
maintainers (if not the head maintainer), so he would know.

Re: CVS Emacs cygwin build problem.

[Richard Stallman]

    >     > Actually, cygwin make has --win32 switch which tells the make to use  
    >     > windows path and etc. I can experiment a little bit and see if there  
    >     > is other problem.

    "Win32" is the proper name of MS-Windows API; I believe this is the
    reason for the name of the option.

It's the Microsoft-chosen name, indeed.  I don't think we should
accept the idea that we should use a name that praises Microsoft
just because Microsoft chose it.

    I don't know who maintains the Cygwin Make, but Chris Faylor...

Thanks.