On 2014-01-14 10:34, Erik Joelsson wrote:
If my memory serves me right, I believe we were uncertain if symlink
resolving was really the way to go and finally decided to do it
because a set configuration should not easily be changed without
configure being rerun.
Example: If a configuration finds compiler /path/to/A which is
actually a symlink to /path/to/B, then if that symlink is changed to
point to /path/to/C, perhaps by installing a new package on the
system, then the configuration should still be pointing to B until you
rerun configure.
I'm not fully convinced that this is the case. I have a urgently nagging
feeling that there were some specific problems I encountered when
introducing this feature. I've done some digging in the mercurial
records, but all I could find was that the symlink resolution was
introduced in build-infra changeset f815c7add5fc, with the description
"Added compiler version check to gcc and Windows CL as well." and which
added symlink resolution the newly added code to extract version
information from the compilers.
However, since I can't point to any test case that will fail, I'll have
to recede. I hope Erik is right and that there was no real problem
encountered that was the case for this code.
And yes, it *is* a problem that most, if not all, of the configure code
base is only tested on an ad-hoc basis when it is implemented. :-( This
makes it virtually impossible for me to point to whatever test I ran
that caused me to implement the code in that way. Unfortunately, that's
a problem without an easy solution.
So, yes Mike, I approve of the patch as well, but with the reservation
that I'm allowed to say "Told ya so!" if it turns out that something
breaks. ;-)
/Magnus
