TOOLCHAIN_FIND_COMPILER removing symlinks?

[Erik Joelsson]

This has bitten me before and for the same reason. I'm not sure why we 
opted to do it this way, but it was probably due to wanting to control 
ccache ourselves. I think it's probably not really required to resolve 
the symlinks. I would like to get Magnus input on this too. (which will 
have to wait until Jan 7.)

/Erik


On 2013-12-19 06:37, Mike Duigou wrote:
> I am working with a compiler toolchain that packages it's  C and C++ compilers in a single executable and then uses symbolic links to disambiguate which function is being requested. Want C? Invoke a symbolic link. Want C++? Invoke a different symbolic link. Same story with it's linkers.
>
> Anyway, this setup runs into problems with the current toolchain.m4 function TOOLCHAIN_FIND_COMPILER which includes
>
> TEST_COMPILER="[$]$1"
> BASIC_REMOVE_SYMBOLIC_LINKS(TEST_COMPILER)
>
> ...
>
> $1="$TEST_COMPILER"
>
> This results in the stripping of the identifying symbolic links away and leaving the compiler path as only the raw executable (which happens to default to being a C compiler).
>
> Is removing the symbolic links actually necessary or required? For my purposes commenting out the final statement, $1="$TEST_COMPILER", results in the right executable name (one of the symbolic links) being written to the spec.gmk
>
> I was also surprised that removing of symbolic links from disguised ccache doesn't consider the --disable-ccache option. In this case it should probably just ignore any user trickery and attempt to proceed naively with compiler it's been given.
>
> Mike