[U-Boot] [PATCH v4 11/13] buildman: Search for *cc instead of *gcc for the compiler

[Jeroen Hofstee <jeroen@myspectrum.nl>]

Hello Simon,

On 05-08-14 16:47, Simon Glass wrote:
> Compiler names normally end with cc, but not always gcc. So update the
> detection logic.
>
> Reported-by: Jeroen Hofstee <jeroen@myspectrum.nl>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v4:
> - Add new patch to search for *cc instead of *gcc
>
> Changes in v3: None
> Changes in v2: None
>
>   tools/buildman/toolchain.py | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
> index 1b9771f..e4fcf1b 100644
> --- a/tools/buildman/toolchain.py
> +++ b/tools/buildman/toolchain.py
> @@ -146,7 +146,7 @@ class Toolchains:
>               for subdir in ['.', 'bin', 'usr/bin']:
>                   dirname = os.path.join(path, subdir)
>                   if verbose: print "      - looking in '%s'" % dirname
> -                for fname in glob.glob(dirname + '/*gcc'):
> +                for fname in glob.glob(dirname + '/*cc'):
>                       if verbose: print "         - found '%s'" % fname
>                       self.Add(fname, True, verbose)
>   

I don't have the time to test this now, but this might have
funny side affects. Since cc itself is commonly a symlink to
gcc / clang etc, it will find the same compiler twice. Not sure
if this is handled correctly.

In my hacky attempt to support this I also stored the actual
compiler name, since it is concatenated with gcc somewhere
else if I recall correctly.

Anyway, unless you are sure this works, I don't mind dropping it,
for the time being. There are some more issues for e.g. FreeBSD,
gcc will get installed in /usr/local/bin and carries a version number
like gcc47 etc. clang on linux is just clang and there is no cc
version etc.

Regards,
Jeroen