>> Fixed now. I wonder if it really ought to be checked in as binary so
>> this doesn't happen?
>
>Personally I think that would cause even more problems (for me at least),
>note that there are plenty of other files that need the \r's stripping in
>order for them to work on Unix, in fact some pre-processors (some versions
>of gcc for example) can't even cope with \r's in header files (if there's a
>\r between a \ and a \n).
>
>The only complete solution is to make sure that all text files have their
>\r's stripped before producing the tar.gz file.
>
>[ footnote - one way to do this is with the new bcp tool - something like:
>
>bcp --boost=boost-path --unix-lines --cvs "." destination-path
>
>will produce a clean copy of all of the boost cvs with \r's stripped from
>text files - we could probably even write a Jamfile that would automate the
>release process come to that. -- end footnote ]
The way we've been doing it for releases is to do a CVS export with the option for Unix line endings. Once we started with that approach, the complaints stopped.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
