On Wed, 14 Oct 2009, jesse wrote: > > Right now, we make a release tarball by running Porting/makerel > > > > I can't see how to avoid that, given that one of its jobs is to > > convert win32/Makefile and win32/makefile.mk to DOS line endings, > > and those are the first things run on win32, so we don't get a post- > > tarball-unpack chance to fix them up. > > I'd actually been meaning to bring this up. > > Where is the documentation about _why_ we do these conversions? There is no documentation that I'm aware of. The reason to convert README.win32 etc to CRLF format was so that you could view these files with notepad.exe, probably the only editor on Windows that doesn't support Unix line endings. The reason to convert *.bat files is that at least command.com (Win9X) won't process them correctly otherwise. I think this is no longer an issue with cmd.exe (WinNT and later), but haven't verified it. There are *no* problems building Perl from sources on Windows if you don't change the line-endings AFAIK. > At least for the mingw case, it's not been a problem for me to build from a > git checkout. > > For 5.11 forward, do these files need DOS line endings? > > If so, do they need to _not_ have DOS line endings in the repo? It's the > 21st century and we all have text editors that know how to deal with > line-endings. I'm all for giving them Unix line endings in the repo and the release and see if anybody complains. :) > Similarly, git can track whether the executable bit should be set on files. > Is there an objection to moving +x from Porting/makerel to the files > themselves? I'm not sure why this was done in a script; Perforce also has no problem tracking the +x bit. The only explanation I can come up with is that someone planned to make it possible to cut a release tarball on a Windows system. In that case the +x from version control would get lost (but running "chmod +x ..." wouldn't restore it either, so this still doesn't make sense). Cheers, -JanThread Previous | Thread Next