On Monday 10 April 2006 8:57 pm, Earnie Boyd wrote:
> > path/to/configure LN_S='cp -p' ...
> > for a situation which may be peculiar to a MinGW GCC build under
> > Cygwin.
> > If you are comfortable with that as a standard Autoconf feature, and
> > you document it properly, then I don't have a problem with it.
> Keith, this is the documented method for overriding autoconf variable
> command determination. If the variable is set on the command line it
> is not determined by configure but passed on to config.status.
Yes, except that prior to Ralf's suggested patch, this would not have
worked correctly for LN_S. Furthermore, `info autoconf' for v2.59 says:
| If you make a link in a directory other than the current
| directory, its meaning depends on whether `ln' or `ln -s' is used.
| To safely create links using `$(LN_S)', either find out which
| form is used and adjust the arguments, or always invoke `ln' in
| the directory where the link is to be created.
| In other words, it does not work to do:
| $(LN_S) foo /x/bar
| Instead, do:
| (cd /x && $(LN_S) foo bar)
While this is subtly different from the case under discussion, if the
invoking script always follows the advice to cd to the directory where
the link is to be created, then the MSYS `ln -s' does work, albeit as
equivalent to `cp -p', even for the case where the final argument is `.',
i.e. the the case of creating a link in the current directory, to a file
elsewhere, which is the issue we originally set out to resolve. In this
respect, I think that the documentation could bear some clarification.
But yes, with Ralf's patch in place, then `configure LN_S='cp -p' ...'
would be the appropriate method to prevent the creation of symbolic
links, regardless of what configure would automatically deduce,
*provided* the associated Makefiles correctly implement $(LN_S) for
specifying the symlink command, based on the autoconf substitution;
I agree that this would then be consistent with standard autoconf