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

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

[avr-libc-dev] Re: sample makefile


From: E. Weddington
Subject: [avr-libc-dev] Re: sample makefile
Date: Tue, 25 Feb 2003 15:44:07 -0700

On 25 Feb 2003 at 23:29, Joerg Wunsch wrote:

> As E. Weddington wrote:
> 
> I didn't think of /the/ sample makefile, but rather of a common
> makefile style between all the (upcoming & existing) example projects.

Makes sense.
 
> > And this brings up another point about line-endings. I know there
> > are issues in WinAVR 20030115 about the Unix line endings in the
> > avr-libc example sources.
> 
> 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.

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.

Eric




reply via email to

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