<div dir="ltr"><div>HI Andre,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 23 Aug 2019 at 20:11, Andre McCurdy &lt;<a href="mailto:armccurdy@gmail.com" target="_blank">armccurdy@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Aug 5, 2019 at 9:06 AM Loic Poulain &lt;<a href="mailto:loic.poulain@linaro.org" target="_blank">loic.poulain@linaro.org</a>&gt; wrote:<br>&gt; Say a company works with an OE internal tree, with open-source and closed-source packages. The company wants to release the tree so that its customers can fully customize the images/distro. The closed sources being only available internally, the company has to generate and handle prebuilt binaries for proprietary packages. Ideally, with a unified public/internal OE tree (same recipes for internal/public build).<br>&gt;<br>&gt; This question is actually similar to an older thread:<br>&gt; <a href="https://marc.info/?l=openembedded-core&amp;m=146779329804683" rel="noreferrer" target="_blank">https://marc.info/?l=openembedded-core&amp;m=146779329804683</a><br>
<br>That very old thread was also referenced recently in a follow up where<br>I shared a later solution, see:<br>
<br>  <a href="http://lists.openembedded.org/pipermail/openembedded-core/2019-July/284896.html" rel="noreferrer" target="_blank">http://lists.openembedded.org/pipermail/openembedded-core/2019-July/284896.html</a></blockquote><div><br></div><div>Thanks, I missed that one.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>&gt; I started to work on this and added a &#39;generate-prebuilt&#39; class which generates a tarball of ${D} in deploy/prebuilts after do_install task. Symmetrically, It&#39;s also possible to create an &#39;install-prebuilt&#39; class which bypasses do_fetch, do_unpack, ..., do_install with noexec flag and instead uncompresses a previously generated prebuilt tarball into ${D} and continue normally. But I would like something smarter, e.g. first trying to check if the SRC_URI is available, if not switching on using the prebuilt package if available (e.g. in a DIR_PREBUILT)...<br>&gt;<br>&gt; Before going further is there already an existing solution for that? do you have any recommendation on the easier/best way to achieve this?<br>
<br>I did initially try the approach of having a single recipe which can<br>automatically support both building from source and extracting a<br>prebuilts tar file, but that (for me anyway) turned out to be a dead<br>end. Building from source requires build dependencies and config<br>options but extracting a prebuilt tar file does not, so the two end up<br>sharing very little... so 90% of the recipe ends up being conditional<br>on which mode it&#39;s running in. The solution I ended up with (see link<br>above) was for the class which creates the prebuilt tar file to also<br>create a dedicated mini recipe to extract it. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>From my experience however an equally hard part of the problem is the<br>distribution of prebuilts. It starts off easy (you share a tar file<br>via email or an ftp site and the receiver manually copies to their<br>downloads directory...) but that doesn&#39;t scale if you need to make<br>regular updates.</blockquote><div><br></div><div>Very good point. maybe having binaries also in a repo could help a bit (e.g. using git LFS).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My solution is discussed a little more in the thread<br>linked to above.<br></blockquote><div><br></div><div>Your solution is interesting and I&#39;ll probably jump on the thread with more questions.</div><div>Having an upstream solution part of oe-core would be nice though.<br></div><br><div>Regards,</div><div>Loic<br></div><div><br></div><div>That&#39;s a very good point <br></div></div></div>