This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: CR's in build tree under Cygwin?


>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

    Grant> When I configured a new build tree using the command line
    Grant> ecosconfig.exe program under Cygwin, all of the text files
    Grant> it created had CR/LF line endings. This caused one of the
    Grant> "make" commands to fail.

    Grant> A quick 2-line shell script with "tr" and then a "file .
    Grant> -type f -exec ..." fixed things so that it built just fine.
    Grant> Nothing impresses the Windows guy looking over you shoulder
    Grant> like nice, cryptic "find" command, but there must be an
    Grant> easier way to do this that doesn't make Win32 users' eyes
    Grant> roll back in their heads.

    Grant> How do others avoid the CR problem when configuring a build
    Grant> tree under Cygwin?

    Grant> Does the Win32 GUI config tool generate files w/o CRs in
    Grant> them?

    Grant> Do people usually have their build trees mounted in "text"
    Grant> mode under Cygwin?

    Grant> [I had assumed that they should be mounted in binary mode
    Grant> since the arm-elf tools built more easily that way...]

No. eCos build trees have to be on drives mounted in text mode. This
is documented behaviour. The problem is that there are some files in
the build tree, e.g. the ecos.ecc savefile, which users will want to
edit. We cannot mandate cygwin-aware editors, e.g. some people might
want to use notepad. Hence the files need to contain cr/lf pairs.

Work has been done on some of the tools, e.g. gcc and (I thought)
make, so that they just ignore spurious carriage returns. Such tricks
can avoid many of the problems people encounter. However there are
complications, for example I believe that a compiler that always just
ignores carriage returns is not standards-compliant.

It is a shame that there are still operating systems out there which
insist on using two characters to mark the end of a line. I believe
Unix systems have managed with just a single character since 1969 or
so.

Bart

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]