RFR: 8031668: (xxs) TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links

[Magnus Ihse Bursie]

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