avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Re: sample makefile


From: Volkmar Dierkes
Subject: Re: [avr-libc-dev] Re: sample makefile
Date: Wed, 26 Feb 2003 00:08:11 +0100
User-agent: 40tude_Dialog/2.0.3.1 Hamster/2.0.0.1

On Tue, 25 Feb 2003 15:44:07 -0700, E. Weddington wrote:

> On 25 Feb 2003 at 23:29, Joerg Wunsch wrote:
>
>> As E. Weddington wrote:

>> Hmm, most Windows tools seem to be able to handle it both ways, but
>> IMHO, one of the AVRstudio versions is too stupid for it.  Except in
>> rare situations (like line continuation with a \ at the end of the
>> line), gcc and all the Unix tools would tolerate \r\n endings as well,
>> but i'm not too thrilled at the idea to poison all our files with CRs
>> now. :) (Even though Emacs handles them transparently.)
>
> Not all Windows editors will handle Unix line endings (LE). The 
> editor that I ship with WinAVR, Programmers Notepad 2, does handle it 
> and support for it is improving.
>
> The other issue has to do with debugging. I remember seeing posts 
> (and I think Volkmar has been the one responding to these) I think it 
> was about the source in the debugging was all on 1 line? Which I 
> believe was due to Unix LE in the source.

Yes, that's right. But this is only important for source files. 
Especially the sample projects which are used for get into WinAVR. I 
see no need for changing all the other stuff (.h, ...).

> I'm not proposing to poison the files with CRs. That's why I 
> mentioned converting them off-line before I ship.
>
>>> I'm planning to do it in a script on my 
>>> end for the next WinAVR release but, again, it might be good to make
>>> that platform dependent. Line ending conversion would also apply to
>>> any sample makefile as well.
>>
>> I think that's hard to do somewhere there, because we've got no notion
>> about which files would need a conversion and which don't.
>
> I would be converting all example source files, .c, .h, makefile. 
> Anything that can, would, and should be edited by a user. Because I 
> can't guarantee that a user's editor can handle Unix LEs.

I agree.

Volkmar




reply via email to

[Prev in Thread] Current Thread [Next in Thread]