
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">

<br class="">

<div>

<blockquote type="cite" class="">

<div class="">On 20 Apr 2017, at 18:46, Renato Golin <<a href="mailto:renato.golin@linaro.org" class="">renato.golin@linaro.org</a>> wrote:</div>

<br class="Apple-interchange-newline">

<div class="">On 20 April 2017 at 17:35, Kristof Beyls <<a href="mailto:Kristof.Beyls@arm.com" class="">Kristof.Beyls@arm.com</a>> wrote:<br class="">

<blockquote type="cite" class="">I think what made it break in this way is installing gcc/g++.<br class="">

</blockquote>

<br class="">

No, the original breakage was complaining gcc didn't exist. Something<br class="">

in LNT is requiring GCC.<br class="">

<br class="">

<br class="">

<blockquote type="cite" class="">Reverting the commit that broke the bot in a different way initially won't make the bot pass again, as gcc/g++ will still be installed.<br class="">

</blockquote>

<br class="">

I have removed it.<br class="">

<br class="">

<br class="">

<blockquote type="cite" class="">I'm assuming that the bot will be fine without gcc/g++ installed, as it was fine before without having it installed.<br class="">

</blockquote>

<br class="">

Most of our buildbots run solely on Clang.<br class="">

<br class="">

<br class="">

<blockquote type="cite" class="">Probably it's only needed when something changes in lnt/lnt/testing/profile/cPerf.cpp.<br class="">

Of course after uninstalling gcc/g++, this will break again once anyone makes another change to cPerf.ccp.<br class="">

I don't expect any in the near future, but you never know.<br class="">

</blockquote>

<br class="">

It'd be good to understand why the build system is requiring GCC...<br class="">

</div>

</blockquote>

<div><br class="">

</div>

<div>The mechanism used is documented here: <a href="https://docs.python.org/2/extending/building.html" class="">https://docs.python.org/2/extending/building.html</a>.</div>

<div>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: <a href="http://stackoverflow.com/questions/16737260/how-to-tell-distutils-to-use-gcc" class="">http://stackoverflow.com/questions/16737260/how-to-tell-distutils-to-use-gcc</a>.</div>

<div><br class="">

</div>

<div>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.</div>

<div><br class="">

</div>

<div>We could consider not having a c++ module in LNT, which would remove the need to build during LNT installation.</div>

<div>The functionality in cPerf.cpp could probably be reimplemented by calling "perf annotate" and text parsing the output of that.</div>

<div>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.</div>

<div>So, whether or not to drop cPerf.cpp and replace it with python code parsing the output of "perf annotate" is a tradeoff between ease of deployment, ease of maintenance and the speed at which the performance tracking bots work.</div>

<div><br class="">

</div>

<div>Thanks,</div>

<div><br class="">

</div>

<div>Kristof</div>

</div>

</body>

</html>