build: Remove the trailing backslash of the last line of Makefiles

Message ID 1334233671-61585-1-git-send-email-martin@martin.st
State Deferred
Headers show

Commit Message

Martin Storsjö April 12, 2012, 12:27 p.m.
The trailing backslash at the last line allegedly causes
issues for make on msys.
---
 libavcodec/arm/Makefile   |    2 +-
 libavcodec/mips/Makefile  |    2 +-
 libavcodec/ppc/Makefile   |    2 +-
 libavcodec/sparc/Makefile |    2 +-
 libavcodec/x86/Makefile   |    2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

Comments

Mans Rullgard April 12, 2012, 12:31 p.m. | #1
Martin Storsjö <martin@martin.st> writes:

> The trailing backslash at the last line allegedly causes
> issues for make on msys.

Allegedly?  We don't do things based purely on hearsay.
Mashiat Sarker Shakkhar April 12, 2012, 12:31 p.m. | #2
On 4/12/2012 6:27 PM, Martin Storsjö wrote:
> The trailing backslash at the last line allegedly causes
> issues for make on msys.
> ---
>   libavcodec/arm/Makefile   |    2 +-
>   libavcodec/mips/Makefile  |    2 +-
>   libavcodec/ppc/Makefile   |    2 +-
>   libavcodec/sparc/Makefile |    2 +-
>   libavcodec/x86/Makefile   |    2 +-
>   5 files changed, 5 insertions(+), 5 deletions(-)
[...]

Fixes compilation under msysgit for me.
Martin Storsjö April 12, 2012, 12:34 p.m. | #3
On Thu, 12 Apr 2012, Måns Rullgård wrote:

> Martin Storsjö <martin@martin.st> writes:
>
>> The trailing backslash at the last line allegedly causes
>> issues for make on msys.
>
> Allegedly?  We don't do things based purely on hearsay.

Right. So s/allegedly// on the commit msg.

// Martin
Mans Rullgard April 12, 2012, 12:47 p.m. | #4
Martin Storsjö <martin@martin.st> writes:

> On Thu, 12 Apr 2012, Måns Rullgård wrote:
>
>> Martin Storsjö <martin@martin.st> writes:
>>
>>> The trailing backslash at the last line allegedly causes
>>> issues for make on msys.
>>
>> Allegedly?  We don't do things based purely on hearsay.
>
> Right. So s/allegedly// on the commit msg.

Why is this a problem on msys and nowhere else?
Diego Biurrun April 12, 2012, 12:55 p.m. | #5
On Thu, Apr 12, 2012 at 01:47:51PM +0100, Måns Rullgård wrote:
> Martin Storsjö <martin@martin.st> writes:
> 
> > On Thu, 12 Apr 2012, Måns Rullgård wrote:
> >
> >> Martin Storsjö <martin@martin.st> writes:
> >>
> >>> The trailing backslash at the last line allegedly causes
> >>> issues for make on msys.
> >>
> >> Allegedly?  We don't do things based purely on hearsay.
> >
> > Right. So s/allegedly// on the commit msg.
> 
> Why is this a problem on msys and nowhere else?

It's a problem with Windows line endings rather than with msys.
The log message should of course be amended to reflect that.

Diego
Mans Rullgard April 12, 2012, 12:56 p.m. | #6
Diego Biurrun <diego@biurrun.de> writes:

> On Thu, Apr 12, 2012 at 01:47:51PM +0100, Måns Rullgård wrote:
>> Martin Storsjö <martin@martin.st> writes:
>> 
>> > On Thu, 12 Apr 2012, Måns Rullgård wrote:
>> >
>> >> Martin Storsjö <martin@martin.st> writes:
>> >>
>> >>> The trailing backslash at the last line allegedly causes
>> >>> issues for make on msys.
>> >>
>> >> Allegedly?  We don't do things based purely on hearsay.
>> >
>> > Right. So s/allegedly// on the commit msg.
>> 
>> Why is this a problem on msys and nowhere else?
>
> It's a problem with Windows line endings rather than with msys.

Please explain.
Diego Biurrun April 12, 2012, 1:12 p.m. | #7
On Thu, Apr 12, 2012 at 01:56:31PM +0100, Måns Rullgård wrote:
> Diego Biurrun <diego@biurrun.de> writes:
> > On Thu, Apr 12, 2012 at 01:47:51PM +0100, Måns Rullgård wrote:
> >> Martin Storsjö <martin@martin.st> writes:
> >> 
> >> > On Thu, 12 Apr 2012, Måns Rullgård wrote:
> >> >
> >> >> Martin Storsjö <martin@martin.st> writes:
> >> >>
> >> >>> The trailing backslash at the last line allegedly causes
> >> >>> issues for make on msys.
> >> >>
> >> >> Allegedly?  We don't do things based purely on hearsay.
> >> >
> >> > Right. So s/allegedly// on the commit msg.
> >> 
> >> Why is this a problem on msys and nowhere else?
> >
> > It's a problem with Windows line endings rather than with msys.
> 
> Please explain.

Windows git will (by default unless instructed otherwise) checkout files
with CRLF line endings.  Files that end in "\CRLF" trip up msys Make.
Quite possibly such files will trip up other Make versions as well.

Diego
Mans Rullgard April 12, 2012, 1:17 p.m. | #8
Diego Biurrun <diego@biurrun.de> writes:

> On Thu, Apr 12, 2012 at 01:56:31PM +0100, Måns Rullgård wrote:
>> Diego Biurrun <diego@biurrun.de> writes:
>> > On Thu, Apr 12, 2012 at 01:47:51PM +0100, Måns Rullgård wrote:
>> >> Martin Storsjö <martin@martin.st> writes:
>> >> 
>> >> > On Thu, 12 Apr 2012, Måns Rullgård wrote:
>> >> >
>> >> >> Martin Storsjö <martin@martin.st> writes:
>> >> >>
>> >> >>> The trailing backslash at the last line allegedly causes
>> >> >>> issues for make on msys.
>> >> >>
>> >> >> Allegedly?  We don't do things based purely on hearsay.
>> >> >
>> >> > Right. So s/allegedly// on the commit msg.
>> >> 
>> >> Why is this a problem on msys and nowhere else?
>> >
>> > It's a problem with Windows line endings rather than with msys.
>> 
>> Please explain.
>
> Windows git will (by default unless instructed otherwise) checkout files
> with CRLF line endings.  Files that end in "\CRLF" trip up msys Make.

Why is this a problem only on the last line?
Diego Biurrun April 12, 2012, 1:32 p.m. | #9
On Thu, Apr 12, 2012 at 02:17:34PM +0100, Måns Rullgård wrote:
> Diego Biurrun <diego@biurrun.de> writes:
> > On Thu, Apr 12, 2012 at 01:56:31PM +0100, Måns Rullgård wrote:
> >> Diego Biurrun <diego@biurrun.de> writes:
> >> > On Thu, Apr 12, 2012 at 01:47:51PM +0100, Måns Rullgård wrote:
> >> >> Martin Storsjö <martin@martin.st> writes:
> >> >> 
> >> >> > On Thu, 12 Apr 2012, Måns Rullgård wrote:
> >> >> >
> >> >> >> Martin Storsjö <martin@martin.st> writes:
> >> >> >>
> >> >> >>> The trailing backslash at the last line allegedly causes
> >> >> >>> issues for make on msys.
> >> >> >>
> >> >> >> Allegedly?  We don't do things based purely on hearsay.
> >> >> >
> >> >> > Right. So s/allegedly// on the commit msg.
> >> >> 
> >> >> Why is this a problem on msys and nowhere else?
> >> >
> >> > It's a problem with Windows line endings rather than with msys.
> >> 
> >> Please explain.
> >
> > Windows git will (by default unless instructed otherwise) checkout files
> > with CRLF line endings.  Files that end in "\CRLF" trip up msys Make.
> 
> Why is this a problem only on the last line?

We can only speculate so far.  However, I can certify that my Linux Make
also gets tripped up when I insert a CRLF Makefile that ends in "\CRLF"
into my Libav tree.

Diego
Mans Rullgard April 12, 2012, 1:36 p.m. | #10
Diego Biurrun <diego@biurrun.de> writes:

> On Thu, Apr 12, 2012 at 02:17:34PM +0100, Måns Rullgård wrote:
>> Diego Biurrun <diego@biurrun.de> writes:
>> > On Thu, Apr 12, 2012 at 01:56:31PM +0100, Måns Rullgård wrote:
>> >> Diego Biurrun <diego@biurrun.de> writes:
>> >> > On Thu, Apr 12, 2012 at 01:47:51PM +0100, Måns Rullgård wrote:
>> >> >> Martin Storsjö <martin@martin.st> writes:
>> >> >> 
>> >> >> > On Thu, 12 Apr 2012, Måns Rullgård wrote:
>> >> >> >
>> >> >> >> Martin Storsjö <martin@martin.st> writes:
>> >> >> >>
>> >> >> >>> The trailing backslash at the last line allegedly causes
>> >> >> >>> issues for make on msys.
>> >> >> >>
>> >> >> >> Allegedly?  We don't do things based purely on hearsay.
>> >> >> >
>> >> >> > Right. So s/allegedly// on the commit msg.
>> >> >> 
>> >> >> Why is this a problem on msys and nowhere else?
>> >> >
>> >> > It's a problem with Windows line endings rather than with msys.
>> >> 
>> >> Please explain.
>> >
>> > Windows git will (by default unless instructed otherwise) checkout files
>> > with CRLF line endings.  Files that end in "\CRLF" trip up msys Make.
>> 
>> Why is this a problem only on the last line?
>
> We can only speculate so far.  However, I can certify that my Linux Make
> also gets tripped up when I insert a CRLF Makefile that ends in "\CRLF"
> into my Libav tree.

I would not expect \crlf to work at all in a Unix make.  Your experiment
is meaningless.
Diego Biurrun April 12, 2012, 1:40 p.m. | #11
On Thu, Apr 12, 2012 at 02:36:23PM +0100, Måns Rullgård wrote:
> Diego Biurrun <diego@biurrun.de> writes:
> > On Thu, Apr 12, 2012 at 02:17:34PM +0100, Måns Rullgård wrote:
> >> Diego Biurrun <diego@biurrun.de> writes:
> >> > On Thu, Apr 12, 2012 at 01:56:31PM +0100, Måns Rullgård wrote:
> >> >> Diego Biurrun <diego@biurrun.de> writes:
> >> >> > On Thu, Apr 12, 2012 at 01:47:51PM +0100, Måns Rullgård wrote:
> >> >> >> Martin Storsjö <martin@martin.st> writes:
> >> >> >> 
> >> >> >> > On Thu, 12 Apr 2012, Måns Rullgård wrote:
> >> >> >> >
> >> >> >> >> Martin Storsjö <martin@martin.st> writes:
> >> >> >> >>
> >> >> >> >>> The trailing backslash at the last line allegedly causes
> >> >> >> >>> issues for make on msys.
> >> >> >> >>
> >> >> >> >> Allegedly?  We don't do things based purely on hearsay.
> >> >> >> >
> >> >> >> > Right. So s/allegedly// on the commit msg.
> >> >> >> 
> >> >> >> Why is this a problem on msys and nowhere else?
> >> >> >
> >> >> > It's a problem with Windows line endings rather than with msys.
> >> >> 
> >> >> Please explain.
> >> >
> >> > Windows git will (by default unless instructed otherwise) checkout files
> >> > with CRLF line endings.  Files that end in "\CRLF" trip up msys Make.
> >> 
> >> Why is this a problem only on the last line?
> >
> > We can only speculate so far.  However, I can certify that my Linux Make
> > also gets tripped up when I insert a CRLF Makefile that ends in "\CRLF"
> > into my Libav tree.
> 
> I would not expect \crlf to work at all in a Unix make.  Your experiment
> is meaningless.

Your expectation is wrong.  Only the last line in the file is a problem.
I inserted libavcodec/x86/Makefile for testing, it has many more \CRLF
line endings.

Diego
Mans Rullgard April 12, 2012, 2:21 p.m. | #12
Diego Biurrun <diego@biurrun.de> writes:

> On Thu, Apr 12, 2012 at 02:36:23PM +0100, Måns Rullgård wrote:
>> Diego Biurrun <diego@biurrun.de> writes:
>> > On Thu, Apr 12, 2012 at 02:17:34PM +0100, Måns Rullgård wrote:
>> >> Diego Biurrun <diego@biurrun.de> writes:
>> >> > On Thu, Apr 12, 2012 at 01:56:31PM +0100, Måns Rullgård wrote:
>> >> >> Diego Biurrun <diego@biurrun.de> writes:
>> >> >> > On Thu, Apr 12, 2012 at 01:47:51PM +0100, Måns Rullgård wrote:
>> >> >> >> Martin Storsjö <martin@martin.st> writes:
>> >> >> >> 
>> >> >> >> > On Thu, 12 Apr 2012, Måns Rullgård wrote:
>> >> >> >> >
>> >> >> >> >> Martin Storsjö <martin@martin.st> writes:
>> >> >> >> >>
>> >> >> >> >>> The trailing backslash at the last line allegedly causes
>> >> >> >> >>> issues for make on msys.
>> >> >> >> >>
>> >> >> >> >> Allegedly?  We don't do things based purely on hearsay.
>> >> >> >> >
>> >> >> >> > Right. So s/allegedly// on the commit msg.
>> >> >> >> 
>> >> >> >> Why is this a problem on msys and nowhere else?
>> >> >> >
>> >> >> > It's a problem with Windows line endings rather than with msys.
>> >> >> 
>> >> >> Please explain.
>> >> >
>> >> > Windows git will (by default unless instructed otherwise) checkout files
>> >> > with CRLF line endings.  Files that end in "\CRLF" trip up msys Make.
>> >> 
>> >> Why is this a problem only on the last line?
>> >
>> > We can only speculate so far.  However, I can certify that my Linux Make
>> > also gets tripped up when I insert a CRLF Makefile that ends in "\CRLF"
>> > into my Libav tree.
>> 
>> I would not expect \crlf to work at all in a Unix make.  Your experiment
>> is meaningless.
>
> Your expectation is wrong.  Only the last line in the file is a problem.
> I inserted libavcodec/x86/Makefile for testing, it has many more \CRLF
> line endings.

So again, what makes the last line special?
Luca Barbato April 12, 2012, 3:58 p.m. | #13
On 12/04/12 05:27, Martin Storsjö wrote:
> The trailing backslash at the last line allegedly causes
> issues for make on msys.
> ---
>  libavcodec/arm/Makefile   |    2 +-
>  libavcodec/mips/Makefile  |    2 +-
>  libavcodec/ppc/Makefile   |    2 +-
>  libavcodec/sparc/Makefile |    2 +-
>  libavcodec/x86/Makefile   |    2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)
> 

What about documenting the issue and the git configuration to be used
instead?

lu
Martin Storsjö April 12, 2012, 6:31 p.m. | #14
On Thu, 12 Apr 2012, Luca Barbato wrote:

> On 12/04/12 05:27, Martin Storsjö wrote:
>> The trailing backslash at the last line allegedly causes
>> issues for make on msys.
>> ---
>>  libavcodec/arm/Makefile   |    2 +-
>>  libavcodec/mips/Makefile  |    2 +-
>>  libavcodec/ppc/Makefile   |    2 +-
>>  libavcodec/sparc/Makefile |    2 +-
>>  libavcodec/x86/Makefile   |    2 +-
>>  5 files changed, 5 insertions(+), 5 deletions(-)
>> 
>
> What about documenting the issue and the git configuration to be used
> instead?

Makefiles with windows newlines used to work, and I don't really see a big 
reason why we wouldn't want to keep that working, instead of trying to 
make the world change - especially for as small reason as this.

IMO (which might just be an opinion and not relevant according to specs or 
similar), terminating the last line with a backslash, especially in 
makefiles that are included in other files, is dubious.

// Martin
Mans Rullgard April 12, 2012, 7:08 p.m. | #15
Martin Storsjö <martin@martin.st> writes:

> On Thu, 12 Apr 2012, Luca Barbato wrote:
>
>> On 12/04/12 05:27, Martin Storsjö wrote:
>>> The trailing backslash at the last line allegedly causes
>>> issues for make on msys.
>>> ---
>>>  libavcodec/arm/Makefile   |    2 +-
>>>  libavcodec/mips/Makefile  |    2 +-
>>>  libavcodec/ppc/Makefile   |    2 +-
>>>  libavcodec/sparc/Makefile |    2 +-
>>>  libavcodec/x86/Makefile   |    2 +-
>>>  5 files changed, 5 insertions(+), 5 deletions(-)
>>>
>>
>> What about documenting the issue and the git configuration to be used
>> instead?
>
> Makefiles with windows newlines used to work,

So why did they stop working?

> and I don't really see a big reason why we wouldn't want to keep that
> working, instead of trying to make the world change - especially for
> as small reason as this.
>
> IMO (which might just be an opinion and not relevant according to
> specs or similar), terminating the last line with a backslash,
> especially in makefiles that are included in other files, is dubious.

I failed to find any mention in the GNU make manual of the last line
being special in this regard.
Martin Storsjö April 12, 2012, 7:16 p.m. | #16
On Thu, 12 Apr 2012, Måns Rullgård wrote:

> So why did they stop working?

Perhaps wecause we might rely on some odd corner case that doesn't behave 
consistently in all gmake variants/use cases?

>> and I don't really see a big reason why we wouldn't want to keep that
>> working, instead of trying to make the world change - especially for
>> as small reason as this.
>>
>> IMO (which might just be an opinion and not relevant according to
>> specs or similar), terminating the last line with a backslash,
>> especially in makefiles that are included in other files, is dubious.
>
> I failed to find any mention in the GNU make manual of the last line
> being special in this regard.

Well, my layman's guess is that the backslash at the last line of a file 
that is included somewhere else either is interpreted as concatenating the 
line with whatever line after the include statement in the including file, 
or merging it with nothing. I'd guess it used to do the latter, but ends 
up doing the former in this case.

// Martin
Diego Biurrun April 12, 2012, 7:19 p.m. | #17
On Thu, Apr 12, 2012 at 09:31:52PM +0300, Martin Storsjö wrote:
> On Thu, 12 Apr 2012, Luca Barbato wrote:
> 
> >On 12/04/12 05:27, Martin Storsjö wrote:
> >>The trailing backslash at the last line allegedly causes
> >>issues for make on msys.
> >>---
> >> libavcodec/arm/Makefile   |    2 +-
> >> libavcodec/mips/Makefile  |    2 +-
> >> libavcodec/ppc/Makefile   |    2 +-
> >> libavcodec/sparc/Makefile |    2 +-
> >> libavcodec/x86/Makefile   |    2 +-
> >> 5 files changed, 5 insertions(+), 5 deletions(-)
> >>
> >
> >What about documenting the issue and the git configuration to be used
> >instead?
> 
> Makefiles with windows newlines used to work,

I just investigated, the commit that triggered the failure is

  commit 7bb3a302feeff37d14a2abb7c7316efa43f8dd5c
  Author: Diego Biurrun <diego@biurrun.de>
  Date:   Tue Mar 27 23:10:02 2012 +0200

    build: Consistently handle conditional compilation for all optimization OBJS.

but only because it created the situation that the last line in a
Makefile ends in a backslash.  If I checkout a revision from before
that commit, unix2dos libavcodec/x86/Makefile and make the last
line end in a backslash, the same issue appears.

So it never worked, it just was never triggered.

That said, I don't particularly care which way the issue is fixed or
worked around.

Diego
Mans Rullgard April 12, 2012, 7:22 p.m. | #18
Martin Storsjö <martin@martin.st> writes:

>>> and I don't really see a big reason why we wouldn't want to keep that
>>> working, instead of trying to make the world change - especially for
>>> as small reason as this.
>>>
>>> IMO (which might just be an opinion and not relevant according to
>>> specs or similar), terminating the last line with a backslash,
>>> especially in makefiles that are included in other files, is dubious.
>>
>> I failed to find any mention in the GNU make manual of the last line
>> being special in this regard.
>
> Well, my layman's guess is that the backslash at the last line of a
> file that is included somewhere else either is interpreted as
> concatenating the line with whatever line after the include statement
> in the including file,

That would be a valid theory if it happened everywhere, not only on
windows when using crlf line endings.
Martin Storsjö April 12, 2012, 7:23 p.m. | #19
On Thu, 12 Apr 2012, Måns Rullgård wrote:

> Martin Storsjö <martin@martin.st> writes:
>
>>>> and I don't really see a big reason why we wouldn't want to keep that
>>>> working, instead of trying to make the world change - especially for
>>>> as small reason as this.
>>>>
>>>> IMO (which might just be an opinion and not relevant according to
>>>> specs or similar), terminating the last line with a backslash,
>>>> especially in makefiles that are included in other files, is dubious.
>>>
>>> I failed to find any mention in the GNU make manual of the last line
>>> being special in this regard.
>>
>> Well, my layman's guess is that the backslash at the last line of a
>> file that is included somewhere else either is interpreted as
>> concatenating the line with whatever line after the include statement
>> in the including file,
>
> That would be a valid theory if it happened everywhere, not only on
> windows when using crlf line endings.

Diego was able to reproduce it on linux, too, when applying crlf line 
endings.

// Martin
Martin Storsjö April 12, 2012, 7:24 p.m. | #20
On Thu, 12 Apr 2012, Diego Biurrun wrote:

> On Thu, Apr 12, 2012 at 09:31:52PM +0300, Martin Storsjö wrote:
>> On Thu, 12 Apr 2012, Luca Barbato wrote:
>>
>>> On 12/04/12 05:27, Martin Storsjö wrote:
>>>> The trailing backslash at the last line allegedly causes
>>>> issues for make on msys.
>>>> ---
>>>> libavcodec/arm/Makefile   |    2 +-
>>>> libavcodec/mips/Makefile  |    2 +-
>>>> libavcodec/ppc/Makefile   |    2 +-
>>>> libavcodec/sparc/Makefile |    2 +-
>>>> libavcodec/x86/Makefile   |    2 +-
>>>> 5 files changed, 5 insertions(+), 5 deletions(-)
>>>>
>>>
>>> What about documenting the issue and the git configuration to be used
>>> instead?
>>
>> Makefiles with windows newlines used to work,
>
> I just investigated, the commit that triggered the failure is
>
>  commit 7bb3a302feeff37d14a2abb7c7316efa43f8dd5c
>  Author: Diego Biurrun <diego@biurrun.de>
>  Date:   Tue Mar 27 23:10:02 2012 +0200
>
>    build: Consistently handle conditional compilation for all optimization OBJS.
>
> but only because it created the situation that the last line in a
> Makefile ends in a backslash.  If I checkout a revision from before
> that commit, unix2dos libavcodec/x86/Makefile and make the last
> line end in a backslash, the same issue appears.
>
> So it never worked, it just was never triggered.

I meant "building the source with windows line endings" used to work, 
since we never triggered this case.

// Martin
Mans Rullgard April 12, 2012, 7:27 p.m. | #21
Martin Storsjö <martin@martin.st> writes:

> On Thu, 12 Apr 2012, Måns Rullgård wrote:
>
>> Martin Storsjö <martin@martin.st> writes:
>>
>>>>> and I don't really see a big reason why we wouldn't want to keep that
>>>>> working, instead of trying to make the world change - especially for
>>>>> as small reason as this.
>>>>>
>>>>> IMO (which might just be an opinion and not relevant according to
>>>>> specs or similar), terminating the last line with a backslash,
>>>>> especially in makefiles that are included in other files, is dubious.
>>>>
>>>> I failed to find any mention in the GNU make manual of the last line
>>>> being special in this regard.
>>>
>>> Well, my layman's guess is that the backslash at the last line of a
>>> file that is included somewhere else either is interpreted as
>>> concatenating the line with whatever line after the include statement
>>> in the including file,
>>
>> That would be a valid theory if it happened everywhere, not only on
>> windows when using crlf line endings.
>
> Diego was able to reproduce it on linux, too, when applying crlf line
> endings.

1. There is only a problem with crlf line endings.
2. Our files contain no crlf line endings.
3. If users modify our code, they are on their own.
4. If there are crlf line endings in a user's files, they must have been
   modified (see 2).
5. This is not our problem.
Martin Storsjö April 12, 2012, 8:45 p.m. | #22
On Thu, 12 Apr 2012, Måns Rullgård wrote:

> Martin Storsjö <martin@martin.st> writes:
>
>> On Thu, 12 Apr 2012, Måns Rullgård wrote:
>>
>>> Martin Storsjö <martin@martin.st> writes:
>>>
>>>>>> and I don't really see a big reason why we wouldn't want to keep that
>>>>>> working, instead of trying to make the world change - especially for
>>>>>> as small reason as this.
>>>>>>
>>>>>> IMO (which might just be an opinion and not relevant according to
>>>>>> specs or similar), terminating the last line with a backslash,
>>>>>> especially in makefiles that are included in other files, is dubious.
>>>>>
>>>>> I failed to find any mention in the GNU make manual of the last line
>>>>> being special in this regard.
>>>>
>>>> Well, my layman's guess is that the backslash at the last line of a
>>>> file that is included somewhere else either is interpreted as
>>>> concatenating the line with whatever line after the include statement
>>>> in the including file,
>>>
>>> That would be a valid theory if it happened everywhere, not only on
>>> windows when using crlf line endings.
>>
>> Diego was able to reproduce it on linux, too, when applying crlf line
>> endings.
>
> 1. There is only a problem with crlf line endings.
> 2. Our files contain no crlf line endings.
> 3. If users modify our code, they are on their own.
> 4. If there are crlf line endings in a user's files, they must have been
>   modified (see 2).
> 5. This is not our problem.

Mmkay, patch dropped for my part then.

// Martin

Patch

diff --git a/libavcodec/arm/Makefile b/libavcodec/arm/Makefile
index e6d9218..8a59278 100644
--- a/libavcodec/arm/Makefile
+++ b/libavcodec/arm/Makefile
@@ -86,4 +86,4 @@  NEON-OBJS                              += arm/dsputil_init_neon.o       \
                                           arm/fmtconvert_neon.o         \
                                           arm/int_neon.o                \
                                           arm/mpegvideo_neon.o          \
-                                          arm/simple_idct_neon.o        \
+                                          arm/simple_idct_neon.o
diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 37899b1..78094d9 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -1,3 +1,3 @@ 
 MMI-OBJS += mips/dsputil_mmi.o                                          \
             mips/idct_mmi.o                                             \
-            mips/mpegvideo_mmi.o                                        \
+            mips/mpegvideo_mmi.o
diff --git a/libavcodec/ppc/Makefile b/libavcodec/ppc/Makefile
index 31f4fb8..4680f99 100644
--- a/libavcodec/ppc/Makefile
+++ b/libavcodec/ppc/Makefile
@@ -18,4 +18,4 @@  ALTIVEC-OBJS                           += ppc/dsputil_altivec.o         \
                                           ppc/gmc_altivec.o             \
                                           ppc/idct_altivec.o            \
                                           ppc/int_altivec.o             \
-                                          ppc/mpegvideo_altivec.o       \
+                                          ppc/mpegvideo_altivec.o
diff --git a/libavcodec/sparc/Makefile b/libavcodec/sparc/Makefile
index 1b6ac81..19bac4d 100644
--- a/libavcodec/sparc/Makefile
+++ b/libavcodec/sparc/Makefile
@@ -1,2 +1,2 @@ 
 VIS-OBJS += sparc/dsputil_vis.o                                         \
-            sparc/simple_idct_vis.o                                     \
+            sparc/simple_idct_vis.o
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 6602cce..3f14f80 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -68,4 +68,4 @@  YASM-OBJS-$(CONFIG_VP8_DECODER)        += x86/vp8dsp.o
 
 YASM-OBJS                              += x86/dsputil_yasm.o            \
                                           x86/deinterlace.o             \
-                                          x86/fmtconvert.o              \
+                                          x86/fmtconvert.o