IIRC I had to set

SHELLOPTS=igncr

globally to force cygwin bash to work with CRLF scripts. On the other
hand I suspect that option is what breaks the autotools generated
configure file for me. So I "correct" configure manually whenever it
is regenerated by replacing '\\r' (see full-text search) with $ac_cr.



Michael



On Tue, Jun 9, 2009 at 11:58 AM, Øyvind Harboe<oyvind.har...@zylin.com> wrote:
> I've had a bit of problems with Cygwin and svn eol native
> option.
>
> I thought I understood what was going on and I went ahead and
> did some changes to svn head, but I have since discovered that
> I do *not* understand what's going on so svn head is a bit in
> limbo...
>
> 1. "guess-rev.sh" was busted because Cygwin will fail to execute
> it when checked out with native. I ran dos2unix and removed the
> native option. It now works.
>
> 2. I ran into problems with Makefile.am and configure.in not having
> Unix line endings and Cygwin failing to run "make maintainer-clean"
> deleting "ltmain.sh" and various other files.
>
> I did some tests and it seemed that the problem "make maintainer-clean"
> problem was due to the svn native option and Cygwin getting confused.
>
> "Great! I thought, I know how to fix that!" So I committed a fix to remove
> svn eol line endings for Makefile.am and configure.in.
>
> Only it didn't fix the problem w/"make maintainer-clean"
>
> So now I have a situation in Cygwin w/Eclipse/Windows svn client
> where:
>
> - I don't know understand why ltmain.sh isn't removed during "make
> maintainer-clean"
> - I saw "ltmain.sh" being removed by "make maintainer-clean" but I
> don't know what I did to make that happen and I can't reproduce
> this behaviour under Cygwin.
> - Makefile.am and configure.in no longer has the svn native line endings
> under in svn head.
> - There is clear evidence that it is *wrong* to use svn eol native for
> .sh files but it is unclear what to do with other files that Cygwin
> reads...
>
> --
> Øyvind Harboe
> Embedded software and hardware consulting services
> http://consulting.zylin.com
> _______________________________________________
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to