Somehow we seemed to have shipped [the abcl-0.15.0 source][1] with a CR+LF file-ending for 'abcl.in', which means when built under a 'NIX one gets the slightly mysterious message "#!/bin/sh -- interpreter not found. It is slightly surprising that we haven't gotten more complaints on this (or maybe everyone builds from SVN?).
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 is local SVN settings
Looking through the SVN log for metadata changes to 'abcl.in' doesn't seem to report anything. Maybe there is somehow to report metadata changes, but I don't see how to do this quickly.
We have the currently unused ability to fix line endings in the relevant Ant targets. Maybe I should revisit them? If so, what would be the correct policy?
[1]: http://downloads.sourceforge.net/armedbear-j/abc/abcl-src-0.15.0.tgz
On Tue, Aug 25, 2009 at 11:16 AM, Mark Evensonevenson@panix.com wrote:
Somehow we seemed to have shipped [the abcl-0.15.0 source][1] with a CR+LF file-ending for 'abcl.in', which means when built under a 'NIX one gets the slightly mysterious message "#!/bin/sh -- interpreter not found. It is slightly surprising that we haven't gotten more complaints on this (or maybe everyone builds from SVN?).
Or everybody builds on Windows? :-)
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?
Bye,
Erik.
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?
On Tue, Sep 1, 2009 at 9:01 AM, Mark Evensonevenson@panix.com wrote:
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.
Which is nice :-)
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'.
Right. The Subversion release manager uses a command line option to check out the sources from the repository where native is interpreted as CRLF for the .zip distribution and as LF for the .tar distribution.
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.
I think I'd like the value of ?? to be dependent on the distribution archive (CRLF for zip and LF for tar.gz). How difficult would it be to build that into build.xml?
Bye,
Erik.
On 9/1/09 9:28 AM, Erik Huelsmann wrote: […]
I think I'd like the value of ?? to be dependent on the distribution archive (CRLF for zip and LF for tar.gz). How difficult would it be to build that into build.xml?
I've implemented this behavior in [svn 12127][1]. Please test when you get a chance.
'abcl.source.{tar,zip}' now explicit changes the EOL for most files to 'lf' (UNIX) for the tar, and to 'crf' (DOS) for the zip. The current exception is that the 'abcl.in' script always gets 'lf' EOL, and the 'abcl.bat.in' always get 'crlf' EOL.
The 'abcl.source.eol' property has been removed.
[1]: http://trac.common-lisp.net/armedbear/changeset/12127
armedbear-devel@common-lisp.net
-
Erik Huelsmann -
Mark Evenson