RE: [patch] remove config.status race condition

[Tim Van Holder]

> First of all, it is not obvious at all that config.status should run
> this, since Tim still did not convince me that AS_LN_S was a good
> thing.  As is, AS_LN_S is just *useless*.  We were happier before.
Hmm:

CONFIG_LINKS code BEFORE:
  ln -s foo bar || ln foo bar

fine, but breaks DJGPP, where the 'ln -s' will succeed, but create a
.exe file instead of the desired link.

CONFIG_LINKS code AFTER:
  $as_ln_s foo bar || ln foo bar
  (should be just $as_ln_s foo bar really, but the '|| ln does no harm')

This does EXACTLY the same thing as the "BEFORE" code (except it uses
the proper command on systems with a broken or missing 'ln -s').
So why were you happier before?

So why is it useless?  It doesn't break anything, but supports MORE
targets!  I really don't see a reason for your reluctance.

I will agree that some of the tests run in AS_SHELL_SANITIZE could/should
be moved elsewhere (or conditionalized) so they are not emitted into
config.status.  There is no reason why config.status should second-guess
the configure script that created it.  But that just means configure
should emit

  as_ln_s="$as_ln_s"

into config.status, not that it should drop as_ln_s entirely.  That
configure itself doesn't use as_ln_s is no excuse either; its purpose
is to provide a working 'ln -s' command for macros, whether those macros
are part of autoconf or user-defined.

> Since AS_LN_S is not solving the problems config.status has, there is
> no reason to have it run by config.status, and in fact, not even by
> configure.  I think including this guy was an error, or, at best, the
> current implementation is just not enough.
Then why have AC_LN_S? If your reasoning is 'ln -s should be right for
everyone', there is no reason to provide a LN_S output variable either.
Seems to me it is strange (possibly even stupid) to check whether a
command is broken for the benefit of the package being configured, but
then continuing to use the broken command yourself.