nt/makefile.w32-in

nt/makefile.w32-in

[Eli Zaretskii]

I notice that nt/makefile.w32-in has DOS EOLs.  This is the only
makefile.w32-in with DOS EOLs, the others have Unix-style newlines at
end of each line.

Is this on purpose?

Re: nt/makefile.w32-in

[Juanma Barranquero]

On 12/21/06, Eli Zaretskii <eliz@gnu.org> wrote:

> I notice that nt/makefile.w32-in has DOS EOLs.  This is the only
> makefile.w32-in with DOS EOLs, the others have Unix-style newlines at
> end of each line.
>
> Is this on purpose?

Probably not.

And BTW, why some ChangeLog files (like msdos/ChangeLog,
mac/ChangeLog, oldXMenu/ChangeLog) have:

  ;; coding: iso-2022-7bit-unix

instead of simply

  ;; coding: iso-2022-7bit

??

They are not binary, so CVSNT checks them out with CR/LF, and then
when editing them from Emacs all lines have ^M at the end.

                    /L/e/k/t/u

Re: nt/makefile.w32-in

[Jason Rumney]

Juanma Barranquero wrote:
> And BTW, why some ChangeLog files (like msdos/ChangeLog,
> mac/ChangeLog, oldXMenu/ChangeLog) have:
>
>  ;; coding: iso-2022-7bit-unix
All the ChangeLog files originally had that tag added. I've removed the 
-unix on the files that I've edited due to the problems you described, 
but those directories are not used by the Windows port, so there is no 
reason for anyone to edit them on Windows (except for msdos, but I guess 
either nothing has changed for a long time, or Eli checks out everything 
with Unix line ends so hasn't seen the problem).

Re: nt/makefile.w32-in

[Juanma Barranquero]

On 12/21/06, Jason Rumney <jasonr@gnu.org> wrote:

> but those directories are not used by the Windows port, so there is no
> reason for anyone to edit them on Windows

I edited all ChangeLog (not ChangeLog.nnn) files a few months ago
while adding the ";; add-log-time-zone-rule: t" local variable. It was
then that I noticed.

                    /L/e/k/t/u

Re: nt/makefile.w32-in

[Eli Zaretskii]

> Date: Thu, 21 Dec 2006 11:37:29 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> but those directories are not used by the Windows port, so there is no 
> reason for anyone to edit them on Windows (except for msdos, but I guess 
> either nothing has changed for a long time, or Eli checks out everything 
> with Unix line ends so hasn't seen the problem).

I always checkout with -kb (and that's the advice nt/INSTALL gives).

But the original question still stands: is there any reason not to
convert nt/makefile.w32-in to Unix EOLs?  Will something in the build
procedure break?

[...time passes...] Ah, I see this entry in nt/ChangeLog:

    2000-09-03  Andrew Innes  <andrewi@gnu.org>

	    * makefile.w32-in: Change to DOS line endings.

So I guess there _was_ a good reason for this, at least in the past,
and we better leave it that way, at least until after the release.

Re: nt/makefile.w32-in

[Lennart Borgman]

Eli Zaretskii wrote:
>> Date: Thu, 21 Dec 2006 11:37:29 +0000
>> From: Jason Rumney <jasonr@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>>
>> but those directories are not used by the Windows port, so there is no 
>> reason for anyone to edit them on Windows (except for msdos, but I guess 
>> either nothing has changed for a long time, or Eli checks out everything 
>> with Unix line ends so hasn't seen the problem).
>>     
>
> I always checkout with -kb (and that's the advice nt/INSTALL gives).
>
> But the original question still stands: is there any reason not to
> convert nt/makefile.w32-in to Unix EOLs?  Will something in the build
> procedure break?
>
> [...time passes...] Ah, I see this entry in nt/ChangeLog:
>
>     2000-09-03  Andrew Innes  <andrewi@gnu.org>
>
> 	    * makefile.w32-in: Change to DOS line endings.
>
> So I guess there _was_ a good reason for this, at least in the past,
> and we better leave it that way, at least until after the release.
>   

Could the reason be that the output from configure.bat has DOS line 
endings? nd/Makefile now has mixed line endings and that looks fragile 
to me.

Re: nt/makefile.w32-in

[Eli Zaretskii]

> Date: Thu, 21 Dec 2006 22:18:10 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: Jason Rumney <jasonr@gnu.org>,  lekktu@gmail.com, 
>  emacs-devel@gnu.org
> >
> >     2000-09-03  Andrew Innes  <andrewi@gnu.org>
> >
> > 	    * makefile.w32-in: Change to DOS line endings.
> >
> > So I guess there _was_ a good reason for this, at least in the past,
> > and we better leave it that way, at least until after the release.
> 
> Could the reason be that the output from configure.bat has DOS line 
> endings?

Probably, some version of Make didn't like Unix EOLs.

> nd/Makefile now has mixed line endings and that looks fragile to me.

After the release, I will convert gmake.defs and nmake.defs to DOS EOL
format.  I don't want to touch them now, as no one complained that it
interferes with the build.

Re: nt/makefile.w32-in

[Lennart Borgman]

Eli Zaretskii wrote:
>> Date: Thu, 21 Dec 2006 22:18:10 +0100
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> CC: Jason Rumney <jasonr@gnu.org>,  lekktu@gmail.com, 
>>  emacs-devel@gnu.org
>>     
>>>     2000-09-03  Andrew Innes  <andrewi@gnu.org>
>>>
>>> 	    * makefile.w32-in: Change to DOS line endings.
>>>
>>> So I guess there _was_ a good reason for this, at least in the past,
>>> and we better leave it that way, at least until after the release.
>>>       
>> Could the reason be that the output from configure.bat has DOS line 
>> endings?
>>     
>
> Probably, some version of Make didn't like Unix EOLs.
>
>   
>> nd/Makefile now has mixed line endings and that looks fragile to me.
>>     
>
> After the release, I will convert gmake.defs and nmake.defs to DOS EOL
> format.  I don't want to touch them now, as no one complained that it
> interferes with the build.
>   

I guess you are pretty sure that this is the right thing to do. Why not 
do it now then? Problems that could occur now just affects people 
checking out code, but if we release it with the problem it can affect 
those users trying to build Emacs quite a long time afterwards.

Re: nt/makefile.w32-in

[Jason Rumney]

Lennart Borgman wrote: 
> I guess you are pretty sure that this is the right thing to do. Why 
> not do it now then? Problems that could occur now just affects people 
> checking out code, but if we release it with the problem it can affect 
> those users trying to build Emacs quite a long time afterwards.

What problems? Noone has reported any problems have they? This is an 
aesthetic change as far as I can see, so it is best left until after the 
release in case it has unforeseen side effects.

Re: nt/makefile.w32-in

[Lennart Borgman]

Jason Rumney wrote:
> Lennart Borgman wrote:
>> I guess you are pretty sure that this is the right thing to do. Why 
>> not do it now then? Problems that could occur now just affects people 
>> checking out code, but if we release it with the problem it can 
>> affect those users trying to build Emacs quite a long time afterwards.
>
> What problems? Noone has reported any problems have they? This is an 
> aesthetic change as far as I can see, so it is best left until after 
> the release in case it has unforeseen side effects.

If we assume the make ports people use does not care about line endings, 
then yes. Otherwise no.

Re: nt/makefile.w32-in

[Juanma Barranquero]

On 12/22/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> If we assume the make ports people use does not care about line endings,
> then yes. Otherwise no.

I think we can safely assume something stronger: that relatively few
people try to build Emacs on Windows (the only build environment where
the [gn]make.defs issue is relevant), and the ones who do are usually
able to gather the info they need to successfully compile Emacs,
whether from a source tarball or from CVS. That's not to say we don't
have to make things easy; but certainly doesn't seem an urgent issue
right now.

(This from yours truly, who twice spent a good deal of time wondering
why nmake refused to work before thinking of checking line endings...)

                    /L/e/k/t/u

Re: nt/makefile.w32-in

[Lennart Borgman]

Juanma Barranquero wrote:
> On 12/22/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>
>> If we assume the make ports people use does not care about line endings,
>> then yes. Otherwise no.
>
> I think we can safely assume something stronger: that relatively few
> people try to build Emacs on Windows (the only build environment where
> the [gn]make.defs issue is relevant), and the ones who do are usually
> able to gather the info they need to successfully compile Emacs,
> whether from a source tarball or from CVS. That's not to say we don't
> have to make things easy; but certainly doesn't seem an urgent issue
> right now.
>
> (This from yours truly, who twice spent a good deal of time wondering
> why nmake refused to work before thinking of checking line endings...)

I was going to write something similar, but my conclusion is different. 
What harm does it make to make the change now then? It will be in the 
release if we make it.

Re: nt/makefile.w32-in

[Juanma Barranquero]

On 12/22/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> What harm does it make to make the change now then?

It works now (we aren't being floored with complains about the line
endings of [gn]make.defs). Can you guarantee without a doubt that the
change won't bring hell for people who's building just fine at the
moment?

> It will be in the release if we make it.

That's not intrinsically good. If it goes in it should be for a reason.

                    /L/e/k/t/u

Re: nt/makefile.w32-in

[Lennart Borgman]

Juanma Barranquero wrote:
> On 12/22/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>
>> What harm does it make to make the change now then?
>
> It works now (we aren't being floored with complains about the line
> endings of [gn]make.defs). Can you guarantee without a doubt that the
> change won't bring hell for people who's building just fine at the
> moment?

No, but I would be very surprised if it did. After all it is not very 
uncommon for a Makefile to have consistent line endings ;-)

Re: nt/makefile.w32-in

[Juanma Barranquero]

On 12/22/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> No, but I would be very surprised if it did. After all it is not very
> uncommon for a Makefile to have consistent line endings ;-)

So the answer is "no, I cannot guarantee it", isn't it? The
possibility of you being surprised by unexpected troubles is unrelated
to the issue.

The rate of bug reports (and new commits) seems to be slowing, at
last. If we refrain from making unnecessary changes perhaps we could
release 22.1 in the near future.

                    /L/e/k/t/u

Re: nt/makefile.w32-in

[Eli Zaretskii]

> Date: Fri, 22 Dec 2006 03:01:02 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: Jason Rumney <jasonr@gnu.org>, Eli Zaretskii <eliz@gnu.org>, 
>  emacs-devel@gnu.org
> >
> > It works now (we aren't being floored with complains about the line
> > endings of [gn]make.defs). Can you guarantee without a doubt that the
> > change won't bring hell for people who's building just fine at the
> > moment?
> 
> No, but I would be very surprised if it did.

Lennart, did you _ever_ happened to manage a release of a software
product?  If you did, you know that making unnecessary changes, just
because it sounds like ``the Right Thing to do'' is a recipe for
releasing unstable software.

> After all it is not very uncommon for a Makefile to have consistent
> line endings ;-)

Who said makefile.w32-in is read only by Make?

Re: nt/makefile.w32-in

[Eli Zaretskii]

> Date: Fri, 22 Dec 2006 00:45:46 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: "Jason Rumney" <jasonr@gnu.org>, "Eli Zaretskii" <eliz@gnu.org>, 
> 	emacs-devel@gnu.org
> 
> (This from yours truly, who twice spent a good deal of time wondering
> why nmake refused to work before thinking of checking line endings...)

This only affects CVS builds, which is not a concern for the release.

However, could you please tell which files' EOLs caused problems in
nmake?

Re: nt/makefile.w32-in

[Juanma Barranquero]

On 12/22/06, Eli Zaretskii <eliz@gnu.org> wrote:

> However, could you please tell which files' EOLs caused problems in
> nmake?

I honestly don't remember, it was long time ago (and I'm not using
MSVC anymore, so I cannot check). It was all fixed by remembering to
use "cvs update -C -kb" on nt/.

If I ever check out a full tree and stumble upon it again I'll make
sure to document the trouble.

                    /L/e/k/t/u

Re: nt/makefile.w32-in

[Eli Zaretskii]

> Date: Thu, 21 Dec 2006 23:48:44 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  lekktu@gmail.com,  emacs-devel@gnu.org,  jasonr@gnu.org
> >
> > After the release, I will convert gmake.defs and nmake.defs to DOS EOL
> > format.  I don't want to touch them now, as no one complained that it
> > interferes with the build.
> 
> I guess you are pretty sure that this is the right thing to do. Why not 
> do it now then?

Because this has been in the code base since December 2001, and no one
complained.  I want to avoid introducing new problems for which we
don't have enough testing time before the release.

Re: nt/makefile.w32-in

[Eli Zaretskii]

> Date: Fri, 22 Dec 2006 13:07:03 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: lekktu@gmail.com, jasonr@gnu.org, emacs-devel@gnu.org
> 
> > Date: Thu, 21 Dec 2006 23:48:44 +0100
> > From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> > CC:  lekktu@gmail.com,  emacs-devel@gnu.org,  jasonr@gnu.org
> > >
> > > After the release, I will convert gmake.defs and nmake.defs to DOS EOL
> > > format.  I don't want to touch them now, as no one complained that it
> > > interferes with the build.
> > 
> > I guess you are pretty sure that this is the right thing to do. Why not 
> > do it now then?
> 
> Because this has been in the code base since December 2001, and no one
> complained.  I want to avoid introducing new problems for which we
> don't have enough testing time before the release.

Actually, the plot thickens.  It turns out Andrew Innes reverted back
to Unix EOLs a short while after the change to DOS EOLs:

    2000-09-17  Andrew Innes  <andrewi@gnu.org>

	    * gmake.defs: Revert to Unix line endings.

	    * nmake.defs: Revert to Unix line endings.

    2000-09-14  Andrew Innes  <andrewi@gnu.org>

	    * makefile.w32-in: Revert to Unix line endings.

    2000-09-03  Andrew Innes  <andrewi@gnu.org>

	    * makefile.w32-in: Change to DOS line endings.


What happened next is two things: on 2001-09-25 the Emacs 21 release
branch was cut, and on 2001-12-03, nt/makefile.w32-in was checked in
on HEAD with this change:

	    (bootstrap-nmake):
	    (bootstrap-gmake): Extend bootstrap process to first do
	    bootstrap-clean in lisp dir and rebuild the DOC file.
	    (bootstrap): Do a "normal" make after the bootstrap work.

(which btw is not in ChangeLog).  This changed the file back to DOS
EOLs as a side effect, evidently by accident.

As a result, all Emacs 21.x releases were shipped with
nt/makefile.w32-in that had Unix EOLs, while in CVS we have DOS EOLs
since December 2001.

So, on the one hand, this makes a very strong argument for changing
the EOLs back to Unix, because all users of Emacs 21.x who built it
did that with Unix EOLs, but OTOH the experience of CVS usage tells us
that the current situation did not cause any trouble since 2001-12.

It is clear that the file should be reverted to Unix EOLs, but now I'm
unsure what, if anything, should we do before the release.

Thoughts?

Re: nt/makefile.w32-in

[Jason Rumney]

Eli Zaretskii wrote:
> It is clear that the file should be reverted to Unix EOLs, but now I'm
> unsure what, if anything, should we do before the release.
>   
I'd say nothing until after release is safest, but first we should 
verify that people have built the pretest with nmake and cygwin make. 
The fact that people have built from CVS with those is no guarantee, 
since people may be used to cleaning up line ends from CVS, either 
manually after checking out, or using CVS command line options.

Re: nt/makefile.w32-in

[Eli Zaretskii]

> Date: Fri, 22 Dec 2006 12:10:33 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: lekktu@gmail.com, emacs-devel@gnu.org
> 
> first we should verify that people have built the pretest with nmake
> and cygwin make.

I don't think we can verify that for Cygwin Make, since Cygwin Make
fails to build Emacs, see nt/INSTALL.

Re: nt/makefile.w32-in

[Jason Rumney]

Eli Zaretskii wrote:
> I don't think we can verify that for Cygwin Make, since Cygwin Make
> fails to build Emacs, see nt/INSTALL.
>   
I was under the impression that it only failed during bootstrap, and 
that some people were accustomed to using it regardless of the advice in 
nt/INSTALL.

Re: nt/makefile.w32-in

[Juanma Barranquero]

On 12/22/06, Eli Zaretskii <eliz@gnu.org> wrote:

> It is clear that the file should be reverted to Unix EOLs,

Agreed.

> but now I'm
> unsure what, if anything, should we do before the release.

We shouldn't try to fix what's not broken. I'd say let's leave it as
is unless pretesters detect any problem with the current situation.
The time to change it is after release.

                    /L/e/k/t/u

Re: nt/makefile.w32-in

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

> Actually, the plot thickens.  It turns out Andrew Innes reverted back
> to Unix EOLs a short while after the change to DOS EOLs:
>
>     2000-09-17  Andrew Innes  <andrewi@gnu.org>
>
> 	    * gmake.defs: Revert to Unix line endings.
>
> 	    * nmake.defs: Revert to Unix line endings.
>
>     2000-09-14  Andrew Innes  <andrewi@gnu.org>
>
> 	    * makefile.w32-in: Revert to Unix line endings.
>
>     2000-09-03  Andrew Innes  <andrewi@gnu.org>
>
> 	    * makefile.w32-in: Change to DOS line endings.

I don't have anything to add directly to this discussion, but it would
help tremendously if people would put _explanations_ in the changelog,
instead of just listing the changes. If we knew _why_ that change was
reverted, we could decide better what to do now!

-- 
-- Stephe

Re: nt/makefile.w32-in

[Eli Zaretskii]

> Cc: lekktu@gmail.com, jasonr@gnu.org, emacs-devel@gnu.org
> From: Stephen Leake <stephen_leake@member.fsf.org>
> Date: Fri, 22 Dec 2006 20:40:07 -0500
> 
> I don't have anything to add directly to this discussion, but it would
> help tremendously if people would put _explanations_ in the changelog,
> instead of just listing the changes.

ChangeLog files are not supposed to explain, just list the changes.
The explanations should be in the comments in the changed file itself.

Re: nt/makefile.w32-in

[Richard Stallman]

    I don't have anything to add directly to this discussion, but it would
    help tremendously if people would put _explanations_ in the changelog,
    instead of just listing the changes.

No, no, no!  Explanations belong in comments in the code.

Would you please look at the comments in these files?
If you think there are important points which are not clear
and which need more explanation, please mention them,
and we can add more explanation of them now.

Re: nt/makefile.w32-in

[Stephen Leake]

Richard Stallman <rms@gnu.org> writes:

>     I don't have anything to add directly to this discussion, but it would
>     help tremendously if people would put _explanations_ in the changelog,
>     instead of just listing the changes.
>
> No, no, no!  Explanations belong in comments in the code.

Ok, that makes sense.

In this case, the issue is whether nt/makefile-w32-in and similar
files should have DOS or Unix line endings.

There are no comments about line endings in the file.

Perhaps it should say:

#  Using DOS line endings for Emacs 22. We've flipflopped on this
#  several times; let's document why we make the next change.

-- 
-- Stephe

Re: nt/makefile.w32-in

[Richard Stallman]

    #  Using DOS line endings for Emacs 22. We've flipflopped on this
    #  several times; let's document why we make the next change.

Good idea -- would someone please install it?
But also please install an explanation of why we made this last change.

Re: nt/makefile.w32-in

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 25 Dec 2006 11:53:04 -0500
> Cc: emacs-devel@gnu.org
> 
>     #  Using DOS line endings for Emacs 22. We've flipflopped on this
>     #  several times; let's document why we make the next change.
> 
> Good idea -- would someone please install it?

Done.

Re: nt/makefile.w32-in

[Eli Zaretskii]

> Date: Thu, 21 Dec 2006 01:03:53 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org, "Jason Rumney" <jasonr@gnu.org>
> 
> And BTW, why some ChangeLog files (like msdos/ChangeLog,
> mac/ChangeLog, oldXMenu/ChangeLog) have:
> 
>   ;; coding: iso-2022-7bit-unix
> 
> instead of simply
> 
>   ;; coding: iso-2022-7bit
> 
> ??

Fixed.

nt/makefile.w32-in

[Eli Zaretskii]

I notice that nt/makefile.w32-in has DOS EOLs.  This is the only
makefile.w32-in with DOS EOLs, the others have Unix-style newlines at
end of each line.

Is this on purpose?

Re: nt/makefile.w32-in

[LENNART BORGMAN]

From: Juanma Barranquero <lekktu@gmail.com>
Date: Friday, December 22, 2006 11:13 am
Subject: Re: nt/makefile.w32-in

> On 12/22/06, Lennart Borgman <lennart.borgman.073@student.lu.se> 
> wrote:
> > No, but I would be very surprised if it did. After all it is not 
> very> uncommon for a Makefile to have consistent line endings ;-)
> 
> So the answer is "no, I cannot guarantee it", isn't it? The
> possibility of you being surprised by unexpected troubles is unrelated
> to the issue.

;-)

What I want to avoid is trouble after the release for those who wants to build themselves with tools that perhaps barks when there are different line endings in Makefile. It seems like this point has somehow totally disappeared from our discussion.

Re: nt/makefile.w32-in

[Eli Zaretskii]

> Date: Fri, 22 Dec 2006 12:34:59 +0100
> From: LENNART BORGMAN <lennart.borgman.073@student.lu.se>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org,
>  Jason Rumney <jasonr@gnu.org>
> 
> What I want to avoid is trouble after the release for those who wants to build themselves with tools that perhaps barks when there are different line endings in Makefile.

What tools are those? can you name them?

The only suspects I can think of is the Cygwin Make, but this Make is
not supported by the native Emacs build anyway, see the compatibility
table in nt/INSTALL.

> It seems like this point has somehow totally disappeared from our discussion.

It didn't disappear, it's just that you are talking about theoretical
problems, while the rest of us are talking about practical ones.

Re: nt/makefile.w32-in

[Juanma Barranquero]

On 12/22/06, LENNART BORGMAN <lennart.borgman.073@student.lu.se> wrote:

> What I want to avoid is trouble after the release for those who
> wants to build themselves with tools that perhaps barks when
> there are different line endings in Makefile.

The CVS is accesible to anyone, and already many people builds from
the CVS instead of waiting for an official release (understandably, I
might add). We don't receive complains about that issue, so it must be
either a non-problem, or at least quite easy to circumvent.

> It seems like this point has somehow totally disappeared from
> our discussion.

No. What seems to be disappearing from this discussion is this
collection of facts:

 - not many people builds on Windows
 - nobody's complaining about the line endings (but you)
 - we're trying to do a release

and your counterarguments are:

 - perhaps it could hypothetically be a problem for someone
 - we can "fix" it, so let's fix it
 - I don't think it will break anything

Excuse me if I don't find them compelling. (Yeah, I know I'm
simplifying your arguments; what are strawmen for? :)

                    /L/e/k/t/u

Re: nt/makefile.w32-in

[Lennart Borgman]

Juanma Barranquero wrote:
> On 12/22/06, LENNART BORGMAN <lennart.borgman.073@student.lu.se> wrote:
>
>> What I want to avoid is trouble after the release for those who
>> wants to build themselves with tools that perhaps barks when
>> there are different line endings in Makefile.
>
> The CVS is accesible to anyone, and already many people builds from
> the CVS instead of waiting for an official release (understandably, I
> might add). We don't receive complains about that issue, so it must be
> either a non-problem, or at least quite easy to circumvent.
>
>> It seems like this point has somehow totally disappeared from
>> our discussion.
>
> No. What seems to be disappearing from this discussion is this
> collection of facts:
>
> - not many people builds on Windows
> - nobody's complaining about the line endings (but you)
> - we're trying to do a release
>
> and your counterarguments are:
>
> - perhaps it could hypothetically be a problem for someone
> - we can "fix" it, so let's fix it
> - I don't think it will break anything
>
> Excuse me if I don't find them compelling. (Yeah, I know I'm
> simplifying your arguments; what are strawmen for? :)

Ok, I give up. But I am not convinced ;-)