Bug 20 - IAR EOL Warning
: IAR EOL Warning
Status: CLOSED FIXED
Product: Atmel Software Framework
common
: v2.0.x
: Other Standalone
: normal priority normal (vote)
: 2.5.0
Assigned To: ASF Maintainers
:
:
:
:
  Show dependency treegraph
 
Reported: 2010-08-13 16:38 CEST by Hunter
Modified: 2011-05-04 10:59 CEST (History)
5 users (show)

See Also:
Public Description:
IAR project (EWP) now suppress the Pa050 warning. Both debug/release configurations are changed.
Development Branch:
Whiteboard:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hunter 2010-08-13 16:38:55 CEST
After compiling an example project in IAR the following warnings appear -
should be an easy fix.

Warning[Pa050]: non-native end of line sequence detected (this diagnostic is
only issued once) <removed>\services\basic\clock\xmega\sysclk.c 3

My guess is the "AVR Software Framework 2.0.0" header that was added includes
an odd char (probably done via linux?).

Found issue in sysclk, pll, and a few others, but surprisingly, not in all
files...
Comment 1 Hans-Christian Egtvedt 2010-08-16 08:18:53 CEST
(In reply to comment #0)
> Warning[Pa050]: non-native end of line sequence detected (this diagnostic is
> only issued once) <removed>\services\basic\clock\xmega\sysclk.c 3

Funny part is that this warning has no affect on IARs ability to read the file,
so it can be ignored. I have not found a way to silence it either.

> My guess is the "AVR Software Framework 2.0.0" header that was added includes
> an odd char (probably done via linux?).

Correct, Linux uses '\n' as end of line, while Windows uses '\r\n' as end of
line.

More info at http://en.wikipedia.org/wiki/Newline#Representations

> Found issue in sysclk, pll, and a few others, but surprisingly, not in all
> files...

That is because some of us develop on a Linux host, while others develop on a
Windows host.

I do not see this being fixed before we move to a build and test server which
points out that stuff like this needs to be fixed. I'll leave it assigned to
me, so I remember to look into it later.
Comment 2 Cyrille Boulanger 2010-12-06 11:26:23 CET
Changing Component to common since the warning happens on AVR32 too.
Comment 3 Dean Camera 2011-02-09 13:44:08 CET
This can be fixed by adding the SVN property svn:eol-style to native on all
source files (not binary files) - this makes the client sanitize the line
endings when files and checked in and out of the repository, storing them LF
endings on the server and converting to the OS's native line endings on
checkout. It can be scripted with a SVN hook, or done server-side.
Comment 4 Hans-Christian Egtvedt 2011-02-09 13:49:35 CET
Actually, they have to all be with CRLF line ending, since IAR barfs on LF line
ending on Unix machines. I don't like to relay on SVN properties, as we might
not stick to SVN forever. This is quite easy to fix of course, but it will
affect loads of files.
Comment 5 Dean Camera 2011-02-09 13:52:28 CET
Ah, wasn't aware IAR had *nix offerings. Nevertheless, setting eol-style to
CRLF would work in the meantime to normalize all files - if the repository
system is changed to (e.g.) GIT in the future, another solution can be found -
no harm done.
Comment 6 Christian Naess 2011-03-18 10:52:26 CET
IAR can be instructed to suppress certain warnings. I've just tested, and
suppressing this warning (Pa050) works fine.

Actions:
Change all IAR project (EWP) templates to enable suppressing of warning Pa050.
Make sure both configurations (debug/release) are changed.

Fixing in
http://norsvn01.norway.atmel.com/apps/appsavr/avr4000_asf_2/branches/main-dev
Comment 7 Christian Naess 2011-03-21 15:47:43 CET
Fixed in SVN revision #15676.

Test build report:
http://ssg-0.norway.atmel.com:9000/builders/build-all/builds/272
Comment 8 Ivar Holand 2011-03-23 16:25:14 CET
Reviewed by: Ivar Holand

This fix looks ok, all files has been updated, and the fix has been verified in
IAR.
Comment 9 Hans-Christian Egtvedt 2011-03-23 16:42:21 CET
(In reply to comment #8)
> Reviewed by: Ivar Holand
> 
> This fix looks ok, all files has been updated, and the fix has been verified in
> IAR.

Doh, reviewed here as well. Tested by compiling files with mixed line ending on
a Linux host, and got no warnings related to line endings.
Comment 10 Xavier Leprévost 2011-04-27 16:45:01 CEST
This bug does not follow the procedure for integration.
It has been fixed in main-dev.
I would be preferable to have a branch for this fix unless someone can confirm
that SVN commit 15676 fix all the issue.
Comment 11 Christian Naess 2011-04-28 15:37:13 CEST
(In reply to comment #10)
> This bug does not follow the procedure for integration.
> It has been fixed in main-dev.
> I would be preferable to have a branch for this fix unless someone can confirm
> that SVN commit 15676 fix all the issue.

That is hereby confirmed.
Comment 12 Christian Naess 2011-04-28 15:49:44 CEST
.
Comment 13 Xavier Leprévost 2011-05-02 11:31:20 CEST
Already review, change to verified fix for integration in main
Comment 14 Stephane Mainchain 2011-05-03 11:34:01 CEST
Seems to be committed in main (svn #17126), should be CLOSED then. Xavier
please check.