<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 23, 2015 at 5:47 AM, Otavio Salvador <span dir="ltr">&lt;<a href="mailto:otavio@ossystems.com.br" target="_blank">otavio@ossystems.com.br</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang &lt;<a href="mailto:liezhi.yang@windriver.com">liezhi.yang@windriver.com</a>&gt; wrote:<br>
&gt; We have several GPLv2 recipes such as <a href="http://m4-native_1.4.9.bb" target="_blank">m4-native_1.4.9.bb</a>, while we also<br>
&gt; have GPLv3&#39;s <a href="http://m4-native_1.4.17.bb" target="_blank">m4-native_<span class="aBn"><span class="aQJ">1.4.17</span></span>.bb</a>, I think that we can remove<br>
&gt; <a href="http://m4-native_1.4.9.bb" target="_blank">m4-native_1.4.9.bb</a> if the target <a href="http://m4_1.4.9.bb" target="_blank">m4_1.4.9.bb</a> builds well ?<br>
&gt;<br>
&gt; I&#39;d like to remove it because we don&#39;t build the lower native version by<br>
&gt; default, and we don&#39;t know whether it works or when it would fail.<br>
<br>
</span>I second this; not tested recipes are always good to remove.</blockquote></div><br>The one case I&#39;d be concerned with is where a native tool is used to crosscompile something for the target, specifically in the case of scripting tools which often have implicit dependency on the exact same version, so it can parse what it needs to parse to build. Python for example, I doubt you&#39;d want to try to use 2.4 as part of the 2.7 crosscompilation process. m4 being a scripting language, that might be the case here. Of course, if the language is compatible between the two versions, maybe that&#39;s a non-issue.<br>-- <br><div class="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>