Can't build latest emacs on MSW + CRLF display issue

Can't build latest emacs on MSW + CRLF display issue

[Vincent Belaïche]

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

Hello,

I have been trying to build the latest emacs on MSWindowsXP + MinGW and
I came across the following issues:

- during the build I get the following error message

In toplevel form:
url/url-proxy.el:24:1:Error: Symbol's function definition is void: cl-member


- during the make-install I get the following error message

gcc -o oo-spd/i386/profile.exe  -gdwarf-2 -g3    oo-spd/i386/profile.o ../lib/oo-spd/i386/libgnu.a oo-spd/i386/ntlib.o   -ladvapi32
mingw32-make.exe[1]: Leaving directory `C:/Programme/GNU/installation/emacs-install/emacs/trunk/lib-src'
mingw32-make.exe[1]: *** No rule to make target `../lisp/international/mule.elc', needed by `DOC'.  Stop.
mingw32-make.exe: *** [all-other-dirs-gmake] Error 2


Anyway, the build has gone far enough so that I have an emacs.exe with
the latest source, and it confirmed a problem which I had with my
previous build, the display of ^M at ends of lines seems buggy:

Here are two pictures:

http://savannah.gnu.org/bugs/download.php?file_id=28919
http://savannah.gnu.org/bugs/download.php?file_id=28920

Both pictures concern visiting info files, but the first one (cr.info)
has the ^M hidden, and the second one (bbdb.info) has the ^M shown.

My feeling is that there is some inconsistency, but maybe I
misunderstood the criterion that triggers ^M hiding.

Both info files have consistent CRLF endings which I checked with the
attached eol_status.cpp tool.

I must say also that I met a problem on bbdb.info which then I could
never reproduce: at some point of time it was displayed w/o the ^M at
for almost the whole file except in the last few tens lines where the ^M
endings were displayed.

VBR,
   Vincent.


[-- Attachment #2: eol_status.cpp --]
[-- Type: text/plain, Size: 1256 bytes --]

#include <iostream>
#include <fstream>
#include <cstring>
#include <string>
using namespace std;


int main(int ac,char const* av[])
{
  if(ac < 2){
	cerr << "Usage: eol_status [FILE]";
	return -1;
  }
  ifstream in(av[1],ios_base::binary);
  if(!in.is_open()){
	cerr << "Can't open file ``"<<av[1]<<"''\n";
	return -2;
  }

  int prev_char = EOF;
  int cur_char;

  int cr_count = 0;
  int lf_count = 0;
  int crlf_count = 0;
  while((cur_char = in.get()) != EOF){
	if(cur_char == 10){
	  if(prev_char == 13)
		++crlf_count;
	  else
		++lf_count;
    }
	else if(prev_char == 13)
      ++cr_count;
	prev_char = cur_char;
  }
  if(prev_char == 13)
	++cr_count;

  if(cr_count != 0 && lf_count == 0 && crlf_count == 0)
	cout << cr_count <<" ends of line are in CR\n";
  else if(cr_count == 0 && lf_count != 0 && crlf_count == 0)
	cout << lf_count <<" ends of line are in LF\n";
  else if(cr_count == 0 && lf_count == 0 && crlf_count != 0)
	cout << crlf_count <<" ends of line are in CRLF\n";
  else  if(cr_count == 0 && lf_count == 0 && crlf_count == 0)
	cout << "Zero end of line\n";
  else
	cout << "Inconsistent end of lines:\n\tCR count   = "<<cr_count
		 << "\n\tLF count   = "<<lf_count
		 << "\n\tCRLF count = "<<crlf_count
		 << "\n";

  return 0;
}

Re: Can't build latest emacs on MSW + CRLF display issue

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr> 
> Date: Sun, 25 Aug 2013 13:52:53 +0200
> Cc: Karl Berry <karl@freefriends.org>
> 
> I have been trying to build the latest emacs on MSWindowsXP + MinGW and
> I came across the following issues:
> 
> - during the build I get the following error message
> 
> In toplevel form:
> url/url-proxy.el:24:1:Error: Symbol's function definition is void: cl-member
> 
> 
> - during the make-install I get the following error message
> 
> gcc -o oo-spd/i386/profile.exe  -gdwarf-2 -g3    oo-spd/i386/profile.o ../lib/oo-spd/i386/libgnu.a oo-spd/i386/ntlib.o   -ladvapi32
> mingw32-make.exe[1]: Leaving directory `C:/Programme/GNU/installation/emacs-install/emacs/trunk/lib-src'
> mingw32-make.exe[1]: *** No rule to make target `../lisp/international/mule.elc', needed by `DOC'.  Stop.
> mingw32-make.exe: *** [all-other-dirs-gmake] Error 2

This method of building Emacs on Windows is deprecated and slowly
bitrots.  See nt/INSTALL.MSYS for the supported method.

Or, if, as I'm guessing, you don't really want to build Emacs, just to
try a recent development snapshot, use one of the places where
precompiled binaries are available (they were announced on this list
not too long ago).

> Anyway, the build has gone far enough so that I have an emacs.exe with
> the latest source, and it confirmed a problem which I had with my
> previous build, the display of ^M at ends of lines seems buggy:
> 
> Here are two pictures:
> 
> http://savannah.gnu.org/bugs/download.php?file_id=28919
> http://savannah.gnu.org/bugs/download.php?file_id=28920
> 
> Both pictures concern visiting info files, but the first one (cr.info)
> has the ^M hidden, and the second one (bbdb.info) has the ^M shown.

The first one, cr.info, doesn't have ^M characters at all, as
evidenced by the "/" mnemonics at the left corner of the mode line.

> My feeling is that there is some inconsistency, but maybe I
> misunderstood the criterion that triggers ^M hiding.

If Emacs shows the ^M characters, it means that either (a) the EOL is
inconsistent, or (b) Emacs decided that the file is binary.  In your
case, the "=" at the left of the mode line suggests the latter
possibility.  Without looking at the file in its entirety, I cannot
tell why that could be the case.

> Both info files have consistent CRLF endings which I checked with the
> attached eol_status.cpp tool.

The best way of checking is to visit the file with
"M-x find-file-literally", then looking for lines that end in ^J
without a ^M.

> I must say also that I met a problem on bbdb.info which then I could
> never reproduce: at some point of time it was displayed w/o the ^M at
> for almost the whole file except in the last few tens lines where the ^M
> endings were displayed.

I suspect that you are producing these Info files in some strange
way.  Perhaps you mix MSYS and MinGW programs, such as install-info
and Perl, or something else.  Mixing MSYS and native programs is known
to produce strange effects wrt EOL format.

Anyway, given the long thread on bug-texinfo about related issues,
what exactly is the purpose of this discussion?  If you think there's
a bug in Emacs's Info reader, then please provide the shortest Info
file that can be used to reproduce the problem, starting with "emacs -Q".
If your goal is something else, please state what that is.

Thanks.

RE: Can't build latest emacs on MSW + CRLF display issue

[Vincent Belaïche]

> Date: Sun, 25 Aug 2013 18:02:51 +0300
> From: eliz@gnu.org
> Subject: Re: Can't build latest emacs on MSW + CRLF display issue
> To: vincent.b.1@hotmail.fr
> CC: karl@freefriends.org; emacs-devel@gnu.org
> 

[...]

> 
> This method of building Emacs on Windows is deprecated and slowly
> bitrots. See nt/INSTALL.MSYS for the supported method.
> 

Ok, I will try that using the autoconf and automake from ezwinports. 

BTW there are also autoconf & automake under the sourceforge mingw
project, but with lesser version number. Your files are for MSYS not
MINGW, right ? And they need the MSYS perl, not the e.g. activestate
perl.

Maybe INSTALL.MSYS should be a bit more talkative about that.

> Or, if, as I'm guessing, you don't really want to build Emacs, just to
> try a recent development snapshot, use one of the places where
> precompiled binaries are available (they were announced on this list
> not too long ago).

Sorry for I missed that. It is true that I was just trying to get a
recent version, but anyway if I can make a build, it is even better.

> 
> > Anyway, the build has gone far enough so that I have an emacs.exe with
> > the latest source, and it confirmed a problem which I had with my
> > previous build, the display of ^M at ends of lines seems buggy:
> > 
> > Here are two pictures:
> > 
> > http://savannah.gnu.org/bugs/download.php?file_id=28919
> > http://savannah.gnu.org/bugs/download.php?file_id=28920
> > 
> > Both pictures concern visiting info files, but the first one (cr.info)
> > has the ^M hidden, and the second one (bbdb.info) has the ^M shown.
> 
> The first one, cr.info, doesn't have ^M characters at all, as
> evidenced by the "/" mnemonics at the left corner of the mode line.
> 

It is a `\' not a `/' mnemonic on the PNG picture, which shows that
cr.info contains consistent CRLF characters, which are not displayed,
because as you are stating later on, cr.info is deemed to be a text file
by EMACS.

I just had a wink at the manual, the eol converion is displayed in mode
line after the coding scheme, like this:

- `:' or `(Unix)' for LF 
- `\' or `(DOS)' for CRLF 
- `/' or (Mac) for CR


> > My feeling is that there is some inconsistency, but maybe I
> > misunderstood the criterion that triggers ^M hiding.
> 
> If Emacs shows the ^M characters, it means that either (a) the EOL is
> inconsistent, or (b) Emacs decided that the file is binary.  In your
> case, the "=" at the left of the mode line suggests the latter
> possibility. Without looking at the file in its entirety, I cannot
> tell why that could be the case.
> 

I agree it is (b) for bbdb.info, I checked that bbdb.info is
consistently encoded with CRLF by using hexl-mode, and then by writing
some eol_status.cpp short program as hexl was not so practical.

So bbdb.info is seen as a binary file using LF end-of-line. That is a
bit surprising given the very large majority of printable characters it
constains.

> > Both info files have consistent CRLF endings which I checked with the
> > attached eol_status.cpp tool.
> 
> The best way of checking is to visit the file with
> "M-x find-file-literally", then looking for lines that end in ^J
> without a ^M.

Thanks for the trick !

> 
> > I must say also that I met a problem on bbdb.info which then I could
> > never reproduce: at some point of time it was displayed w/o the ^M at
> > for almost the whole file except in the last few tens lines where the ^M
> > endings were displayed.
> 
> I suspect that you are producing these Info files in some strange
> way. Perhaps you mix MSYS and MinGW programs, such as install-info
> and Perl, or something else. Mixing MSYS and native programs is known
> to produce strange effects wrt EOL format.
> 

Well, it is true that I was doing some not so orthodox things, and I
also thought in the beginning that Texinfo was the one to blame. There
was two reasons for that:
- I had already met such kind of issue in the past, especially in the
  INFO-DIR-SECTION
- I was not aware that EMACS could make some decision that an info file
  is a binary file and force ^M display even if EOL's are
  consistent. What surprised me was that info files may be handled
  either like text file, or like binary files depending on the constent.
- I must admit that I was not enough paying attention to the more line.

> Anyway, given the long thread on bug-texinfo about related issues,
> what exactly is the purpose of this discussion? 
> If you think there's a bug in Emacs's Info reader, 

No problem with the info reader, that was happening with visiting the
info files. Viewing them like info is perfect.

I was visiting them to check the EOL consistency because as I wrote I
already had issues with that.

At some point of time I got some display that the beginning of file has
no ^M displayed and the end of file has. 

Unfortunately I could not reproduce this, and I did not take any screen
capture, because I was thinking the problem was from the file itself,
and not its displaying. 

I am now almost sure that the files were always the same, but since I
could not reproduce the issue in neither way I cannot be 100% sure.

I have experienced that with a 2013-04-08 build of EMACS, and my only
objective was to make you know about it: Karl informed me that there
already was such kind of ^M display issues. This is why I wanted to make
you know.

> then please provide the shortest Info file that can be used to
> reproduce the problem, starting with "emacs -Q".  If your goal is
> something else, please state what that is.
> 

I am not asking for anything, my sole goal was to inform you, and I
cannot provide more information than is in this email. If ever I can
reproduce that I will be more careful and try to get a screen capture
for you.

> Thanks.
> 
>
Thank you very much for the hint at the new way to build. And sorry for
the much ado for so little a thing.

   Vincent.

Re: Can't build latest emacs on MSW + CRLF display issue

[Glenn Morris]

Eli Zaretskii wrote:

> This method of building Emacs on Windows is deprecated and slowly
> bitrots.  See nt/INSTALL.MSYS for the supported method.

If you don't want to remove this old method (I really don't get this,
but we've been over this before), can it at least print a big fat
warning when it starts, maybe even with a "press return to continue at
your own risk" or somesuch. (Maybe it does this already.)

Re: Can't build latest emacs on MSW + CRLF display issue

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Vincent Belaïche <vincent.b.1@hotmail.fr>,
>   karl@freefriends.org,  emacs-devel@gnu.org
> Date: Sun, 25 Aug 2013 15:00:44 -0400
> 
> Eli Zaretskii wrote:
> 
> > This method of building Emacs on Windows is deprecated and slowly
> > bitrots.  See nt/INSTALL.MSYS for the supported method.
> 
> If you don't want to remove this old method (I really don't get this,
> but we've been over this before), can it at least print a big fat
> warning when it starts, maybe even with a "press return to continue at
> your own risk" or somesuch. (Maybe it does this already.)

Feel free to add that, I don't want to invest even a few seconds of my
time on this.  It isn't worth it, what with 2 people in a couple of
months who needed to be told about that.

Re: Can't build latest emacs on MSW + CRLF display issue

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr> 
> Cc: emacs-devel@gnu.org, Karl Berry <karl@freefriends.org> 
> Date: Sun, 25 Aug 2013 20:54:01 +0200
> 
> BTW there are also autoconf & automake under the sourceforge mingw
> project, but with lesser version number. Your files are for MSYS not
> MINGW, right ?

Right.

> And they need the MSYS perl, not the e.g. activestate perl.
> 
> Maybe INSTALL.MSYS should be a bit more talkative about that.

It is as talkative as needed, but no more talkative.  It tells you to
get everything from MSYS Base, and a additional packages, including
Perl.  If you do that, you are all set.

> > The first one, cr.info, doesn't have ^M characters at all, as
> > evidenced by the "/" mnemonics at the left corner of the mode line.
> > 
> 
> It is a `\' not a `/' mnemonic on the PNG picture, which shows that
> cr.info

Right, sorry, I was looking at the wrong mode line ;-)

> because as you are stating later on, cr.info is deemed to be a text file
> by EMACS.

It is deemed a text file with DOS CRLF EOL format, yes.

> No problem with the info reader, that was happening with visiting the
> info files. Viewing them like info is perfect.

Then what you see is expected: a typical Info file has binary null
bytes in it, so visiting it will show the ^M, because Emacs detects
those null bytes and visits the file without any conversions,
including no EOL conversion.  Viewing the file in Info suppresses the
detection of null bytes, so you don't see the ^M.  I guess cr.info
doesn't have those null bytes (it depends on its Texinfo source).

Re: Can't build latest emacs on MSW + CRLF display issue

[Glenn Morris]

Eli Zaretskii wrote:

>> If you don't want to remove this old method (I really don't get this,
>> but we've been over this before), can it at least print a big fat
>> warning when it starts, maybe even with a "press return to continue at
>> your own risk" or somesuch. (Maybe it does this already.)
>
> Feel free to add that, I don't want to invest even a few seconds of my
> time on this. 

I'd much rather remove it all together, but you won't allow it.
Therefore we are stuck in this state.

RE: Can't build latest emacs on MSW + CRLF display issue

[Vincent Belaïche]

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



> From: rgm@gnu.org
> To: eliz@gnu.org
> Subject: Re: Can't build latest emacs on MSW + CRLF display issue
> Date: Sun, 25 Aug 2013 15:40:44 -0400
> CC: vincent.b.1@hotmail.fr; emacs-devel@gnu.org; karl@freefriends.org
> 
> Eli Zaretskii wrote:
> 
> >> If you don't want to remove this old method (I really don't get this,
> >> but we've been over this before), can it at least print a big fat
> >> warning when it starts, maybe even with a "press return to continue at
> >> your own risk" or somesuch. (Maybe it does this already.)
> >
> > Feel free to add that, I don't want to invest even a few seconds of my
> > time on this. 
> 
> I'd much rather remove it all together, but you won't allow it.
> Therefore we are stuck in this state.
> 

I took the freedom to make it a little more elaborate to stick to Glenn's first idea to have some kind of confirmation request and BIG FAT warning.
Well, it happened that when I wanted to commit my change I realized that Glenn had already done it, and so I just merged what I had done.
   Vincent. 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1521 bytes --]

Re: Can't build latest emacs on MSW + CRLF display issue

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Sun, 25 Aug 2013 15:40:44 -0400
> Cc: vincent.b.1@hotmail.fr, emacs-devel@gnu.org, karl@freefriends.org
> 
> Eli Zaretskii wrote:
> 
> >> If you don't want to remove this old method (I really don't get this,
> >> but we've been over this before), can it at least print a big fat
> >> warning when it starts, maybe even with a "press return to continue at
> >> your own risk" or somesuch. (Maybe it does this already.)
> >
> > Feel free to add that, I don't want to invest even a few seconds of my
> > time on this. 
> 
> I'd much rather remove it all together, but you won't allow it.
> Therefore we are stuck in this state.

With any other deprecated feature, we usually let it linger for quite
some time before deleting it.  I have no idea why this particular case
should be different (nor, for that matter, why it triggers such strong
emotions).

RE: Can't build latest emacs on MSW + CRLF display issue

[Vincent Belaïche]

>
>
>From: vincent.b.1@hotmail.fr
>To: rgm@gnu.org; eliz@gnu.org
>Subject: RE: Can't build latest emacs on MSW + CRLF display issue
>Date: Sun, 25 Aug 2013 22:18:57 +0200
>CC: karl@freefriends.org; emacs-devel@gnu.org
>
>
>
>> From: rgm@gnu.org
>> To: eliz@gnu.org
>> Subject: Re: Can't build latest emacs on MSW + CRLF display issue
>> Date: Sun, 25 Aug 2013 15:40:44 -0400
>> CC: vincent.b.1@hotmail.fr; emacs-devel@gnu.org; karl@freefriends.org
>> 
>> Eli Zaretskii wrote:
>> 
>> >> If you don't want to remove this old method (I really don't get this,
>> >> but we've been over this before), can it at least print a big fat
>> >> warning when it starts, maybe even with a "press return to continue at
>> >> your own risk" or somesuch. (Maybe it does this already.)
>> >
>> > Feel free to add that, I don't want to invest even a few seconds of my
>> > time on this. 
>> 
>> I'd much rather remove it all together, but you won't allow it.
>> Therefore we are stuck in this state.
>> 
>
>I took the freedom to make it a little more elaborate to stick to
>Glenn's first idea to have some kind of confirmation request and BIG
>FAT warning.
>
>Well, it happened that when I wanted to commit my change I realized
>that Glenn had already done it, and so I just merged what I had done.
>
>   Vincent.

BTW, it still does not compile, even with INSTALL.MSYS way I have the
cl-member function definition is void error message.

-----------------------------------------------------------------------
Wrote c:/Programme/GNU/installation/emacs-install/emacs/trunk/lisp/progmodes/meta-mode.elc
Compiling progmodes/mixal-mode.el
Wrote c:/Programme/GNU/installation/emacs-install/emacs/trunk/lisp/progmodes/mixal-mode.elc
Compiling progmodes/modula2.el

In toplevel form:
progmodes/modula2.el:113:1:Error: Symbol's function definition is void: cl-member
make[2]: *** [progmodes/modula2.elc] Error 1
make[2]: Leaving directory `/c/Programme/GNU/installation/emacs-install/emacs/trunk/lisp'
make[1]: *** [compile-main] Error 2
make[1]: Leaving directory `/c/Programme/GNU/installation/emacs-install/emacs/trunk/lisp'
make: *** [lisp] Error 2
-----------------------------------------------------------------------

Maybe modula2.el misses some declare-function or (eval-when-compile
(require 'cl)) statement...

   Vincent.

Re: Can't build latest emacs on MSW + CRLF display issue

[Eli Zaretskii]

> From: vincent.belaiche@gmail.com (Vincent Belaïche)
> Cc: emacs-devel@gnu.org, Karl Berry <karl@freefriends.org> 
> Date: Mon, 26 Aug 2013 08:06:08 +0200
> 
> BTW, it still does not compile, even with INSTALL.MSYS way I have the
> cl-member function definition is void error message.
> 
> -----------------------------------------------------------------------
> Wrote c:/Programme/GNU/installation/emacs-install/emacs/trunk/lisp/progmodes/meta-mode.elc
> Compiling progmodes/mixal-mode.el
> Wrote c:/Programme/GNU/installation/emacs-install/emacs/trunk/lisp/progmodes/mixal-mode.elc
> Compiling progmodes/modula2.el
> 
> In toplevel form:
> progmodes/modula2.el:113:1:Error: Symbol's function definition is void: cl-member
> make[2]: *** [progmodes/modula2.elc] Error 1

Did you try removing smie.elc and saying "make" again?

If that doesn't work, try removing all of the *.elc files first.

Re: Can't build latest emacs on MSW + CRLF display issue

[Glenn Morris]

I'm not trying to be difficult here, I really just don't understand
your logic.

Reasons to remove the old method:
1) It's unsupported and out-of-date (eg I know it doesn't build all the
manuals. Minor but still a bug.).

2) There's no need to have two separate methods to build Emacs on
MS Windows.

3) The new method is obviously preferable since it is the same method
used on all other platforms (except MS DOS).

Even if 1) changes (and it shows no sign of doing so), 2) and 3) never will.


On the other hand, I can't think of a single reason to _not_ remove it.

If someone turns up and wants to do 1), it will be the least of their
problems to first revert the commit that removed the old method. (But
we should not let them anyway, because of 2 and 3.)


(BTW, I suggest at least renaming nt/INSTALL to nt/INSTALL.OLD, and
INSTALL.MSYS to INSTALL.)

Re: Can't build latest emacs on MSW + CRLF display issue

[Vincent Belaïche]

Eli Zaretskii a écrit :
>> From: vincent.belaiche@gmail.com (Vincent Belaïche)
>> Cc: emacs-devel@gnu.org, Karl Berry <karl@freefriends.org> 
>> Date: Mon, 26 Aug 2013 08:06:08 +0200
>>
>> BTW, it still does not compile, even with INSTALL.MSYS way I have the
>> cl-member function definition is void error message.
>>
>> -----------------------------------------------------------------------
>> Wrote c:/Programme/GNU/installation/emacs-install/emacs/trunk/lisp/progmodes/meta-mode.elc
>> Compiling progmodes/mixal-mode.el
>> Wrote c:/Programme/GNU/installation/emacs-install/emacs/trunk/lisp/progmodes/mixal-mode.elc
>> Compiling progmodes/modula2.el
>>
>> In toplevel form:
>> progmodes/modula2.el:113:1:Error: Symbol's function definition is void: cl-member
>> make[2]: *** [progmodes/modula2.elc] Error 1
>
> Did you try removing smie.elc and saying "make" again?
>

[...]

Thanks, that has worked, and it reconfirmed that if ever any remaining
issue with ^M display, that is impossible for me to reproduce.

BR,
   Vincent.

Re: Can't build latest emacs on MSW + CRLF display issue

[Vincent Belaïche]

Hello Glenn,

> From: rgm@gnu.org
> To: eliz@gnu.org
> Subject: Re: Can't build latest emacs on MSW + CRLF display issue
> Date: Mon, 26 Aug 2013 21:46:03 -0400
> CC: emacs-devel@gnu.org
> 
> 
> I'm not trying to be difficult here, I really just don't understand
> your logic.
> 
> Reasons to remove the old method:
> 1) It's unsupported and out-of-date (eg I know it doesn't build all the
> manuals. Minor but still a bug.).
> 
> 2) There's no need to have two separate methods to build Emacs on
> MS Windows.
> 
> 3) The new method is obviously preferable since it is the same method
> used on all other platforms (except MS DOS).
> 
> Even if 1) changes (and it shows no sign of doing so), 2) and 3) never will.
> 
> 
> On the other hand, I can't think of a single reason to _not_ remove it.
> 
> If someone turns up and wants to do 1), it will be the least of their
> problems to first revert the commit that removed the old method. (But
> we should not let them anyway, because of 2 and 3.)
> 
> 
> (BTW, I suggest at least renaming nt/INSTALL to nt/INSTALL.OLD, and
> INSTALL.MSYS to INSTALL.)
> 

Not sure whether this email above was addressed to me or to Eli. Sorry
if I did something wrong with adding the user's confirmation in the
configure.bat.

Is that your concern ?

I was just trying to stick better to your original proposal (big fat
warning + user's confirmation to go on at his/her own risks). Maybe I
misinterpreted what you suggested, as I had not followed the full
discussion on building for MSW.


   Vincent.

PS-1: Personnally I don't mind if the .bat file is removed. But at least
keeing it has the advantage that if a user --- like me --- used his/her
legacy own MSDOS script to do all the job of

- update the source
- configure PATH for the build to work properly
- launch configure.bat with all the wanted options and then make

then this user will receive a clear warning why this old automated way
won't work, so he/she can easily update his script (or rather rewrite it
fully as a BASH script) to use the new build method. And therefore this
user will be less likely to come to this forum like I did and bother
everyone with questions.

PS-2: Your suggestion to rename the INSTALL files is excellent.

Re: Can't build latest emacs on MSW + CRLF display issue

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 26 Aug 2013 21:46:03 -0400
> 
> On the other hand, I can't think of a single reason to _not_ remove it.

The only reason is to let people have time to adapt to the change.

> If someone turns up and wants to do 1), it will be the least of their
> problems to first revert the commit that removed the old method.

Not if they build out of the release (or release-like) tarball.

Re: Can't build latest emacs on MSW + CRLF display issue

[Glenn Morris]

Eli Zaretskii wrote:

>> On the other hand, I can't think of a single reason to _not_ remove it.
>
> The only reason is to let people have time to adapt to the change.

This only makes sense if the old method is still being updated and
supported, which it isn't. It is already incomplete.

Plus, there are pre-built binaries being supplied, so anyone who can't
adapt (for some reason) is already covered.

>> If someone turns up and wants to do 1), it will be the least of their
>> problems to first revert the commit that removed the old method.
>
> Not if they build out of the release (or release-like) tarball.

I hope we don't include an out-of-date, untested build process in the
next release. There are pre-built binaries of releases anyway, so again
I don't see the issue.

Re: Can't build latest emacs on MSW + CRLF display issue

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 27 Aug 2013 14:54:17 -0400
> 
> Eli Zaretskii wrote:
> 
> >> On the other hand, I can't think of a single reason to _not_ remove it.
> >
> > The only reason is to let people have time to adapt to the change.
> 
> This only makes sense if the old method is still being updated and
> supported, which it isn't. It is already incomplete.

I think it makes sense as long as it allows one to build a working
binary.  It still does that, AFAIK.

> Plus, there are pre-built binaries being supplied, so anyone who can't
> adapt (for some reason) is already covered.

That doesn't cover the ability to make changes, something without
which Free Software isn't.

> >> If someone turns up and wants to do 1), it will be the least of their
> >> problems to first revert the commit that removed the old method.
> >
> > Not if they build out of the release (or release-like) tarball.
> 
> I hope we don't include an out-of-date, untested build process in the
> next release.

We will cross that bridge when we get to it (if it will need to be
crossed).

> There are pre-built binaries of releases anyway, so again
> I don't see the issue.

See above: I do see the issue.