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

Simon Glass
2014-08-05T18:25:12Z

Hi Jeroen,

On 5 August 2014 11:41, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
> 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.

OK let's drop it for now until we are clear what is required.

Regards,
Simon