Re: link-follow and mingw

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Jim Meyering on 9/22/2009 7:08 AM:
> At first I wondered why it would be necessary to unlink sym, a file
> named "conftest.sym" here, when right after this test, the usual
> rm -fr conftest* would remove it for us?  Then I looked, and see
> that what I recalled is no longer the case.  While in some places,
> autoconf-generated configure files do indeed run
> 
>     rm -f conftest*
> 
> it's not run after this sort of test.
> Here, this is what's (now?) run:
> 
>     rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
>       conftest.$ac_objext conftest.beam conftest.$ac_ext
> 
> and that doesn't remove the carefully-named temporary file.

I think autoconf has always tried to only remove compiler files at the end
of AC_*_IFELSE, leaving other files in place in case subsequent shell code
needed to inspect the contents of the file.  In other words, I don't think
the rm -f conftest.* done by autoconf has ever been done throughout the
configure script, but only once at the end.

> Has autoconf changed this over the years?

I'd have to research it further for a definitive answer, but if it
changed, it was years ago.

> Or is this accidental fall-out from some other change?

I think this particular failure case has been latent, and was only
recently exposed due to my change in semantics to link-follow.m4 to swap
the sense of success.  It used to be that failure to run the link-follow
test was considered as success for the cache variable, while success in
running the code set LINK_FOLLOWS_SYMLINK to nonzero; but now that we know
we _want_ link that does not follow symlink, I reordered the test earlier
this month, and that's where the latent use of conftest.sym finally
changed the sense of the test on Linux.

> I don't have time to investigate right now,
> but will eventually audit for other assumptions like this.

A good rule of thumb in writing autoconf macros is to clean up any files
you directly created, which are unrelated to compiler side-effects.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq5d/QACgkQ84KuGfSFAYCT9wCfeajOL82U58IzqtqCR58BE7oa
LzEAn2nqXm1iy8ySkOOhiHSrQIKXg36C
=Kb2n
-----END PGP SIGNATURE-----