On 8/31/09 11:30 PM, Erik Huelsmann wrote: […]
The svn:eol-style is now set to 'LF' in SVN for 'abcl.in', which does the "right thing" when building the source tar balls, so abcl-0.16 should be ok, as long as whoever builds the release doesn't somehow override this local SVN setting
Well, I haven't changed the local settings while creating any of the releases, but abcl.in is part of the abcl.dist.misc target, which is part of one of the FIXCRLF elements. Could that be the issue?
Unless you run the build with the 'abcl.source.eol' property set to something other than 'asis' there should be no change of eol from whst comes out of SVN. Currently, the 'fixcrlf' command in the 'abcl.source.prepare' runs with the 'abcl.source.eol' set to 'asis' which does nothing in the transformation. As I remember the implementation history here, I developed this target around the same time we moved to SVN, so we ended up fixing everything in the SVN properties, instead of relying on Ant.
I think the EOL setting in the repository can be overridden by configuration options in the SVN client, so this might be another source of error. And I think using the cygwin SVN client under win32 gets you UNIX line-endings 'LF' for files with svn:eol-style set to 'native', while using the native SVN release (or TortoiseSVN) gets you 'CRLF'.
On the basis of so much possible variation, I guess I would recommend we start using <fixcrlf> with more restrictive defensive settings.
Would these be:
LF -- 'abcl.in' as it is always used under a UNIX-like shell
CRLF -- 'abcl.bat.in' as it is always used under a DOS command shell
?? -- All other source files
But what value should '??' be? One possibility is that it would be 'LF' for 'abcl.source.tar', and 'CRLF' for 'abcl.source.zip', which would take a bit of work with the Ant targets.
Comments?