[cPerf] LNT error on LLD bot

[Renato Golin via llvm-commits]

On 21 April 2017 at 09:31, Kristof Beyls <Kristof.Beyls at arm.com> wrote:
> The mechanism used is documented here:
> https://docs.python.org/2/extending/building.html.
> There doesn't seem to be a documented way to specify a non-default compiler,
> but some stackoverflow answers suggest setting the CC environment variable:
> http://stackoverflow.com/questions/16737260/how-to-tell-distutils-to-use-gcc.

That doesn't seem to help. I only have Clang installed, "$CC" is not
set, my "cc" is "Clang":

$ cc -v
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)

and the Python infrastructure didn't choose "gcc", but
"aarch64-linux-gnu-gcc" which is a long way from anything plausible by
"just grabbing the default compiler".


> In summary, I think we shouldn't try to fiddle with this in the LNT package
> and just keep on following standard Python practice to avoid more
> hard-to-understand breakage.

I think that mechanism is completely broken, assuming too much, and
the only way I can "fix" it right now is to create a symlink from
"aarch64-linux-gnu-gcc" to "clang".


> We could consider not having a c++ module in LNT, which would remove the
> need to build during LNT installation.
> The functionality in cPerf.cpp could probably be reimplemented by calling
> "perf annotate" and text parsing the output of that.
> However, James tells me that "perf annotate" is about 6 times slower than
> the code in cPerf.cpp, and that is even without parsing the output of perf
> annotate.

I can imagine.

Another alternative would be for us to build it before we even get to
python, and ignore any python-eske shenanigans.

--renato