Re: Building "restricted" source code

[Mark Hatle <mark.hatle@windriver.com>]

On 3/26/13 7:53 AM, Jerrod Peach wrote:
> As part of my company's firmware builds, we have to build some code that only a
> handful of developers are allowed to view.  We call this restricted source code.
>   Getting our official "system" builds to build this code isn't a problem.  What
> is a problem is a regular developer's build of this code.
>
> Imagine this scenario: The restricted source depends upon eglibc.  Our low-level
> team, who doesn't have access to the restricted source, updates the recipe for
> eglibc.  The hash for the restricted package is permuted, and so they can't get
> an sstate hit and are required to rebuild the source.  But, since they can't
> check out the source, they can't build it.  This would cause a build failure.
>
> Is anyone dealing with this scenario while using Yocto currently?  If so, how?
>   I know it may be unlikely that many people are hitting this since Yocto is
> primarily used to build open-source code, but I thought I'd take a shot in the
> dark and hope for the best.  :-)
>

Two ways I know of doing this.  Slightly different way of doing things:

1) If the code does -not- rely on outside influences, such as eglibc.  Configure 
the recipe and pretty much ignore everything else with a vardepsexp.  Then ship 
the sstate-cache files that cover the compiled code.  (Along with the original 
recipe...)

2) For code that DOES rely on outside influences.. create a custom recipe that 
either downloads the source and builds it [if the user has access to the 
source], or will pull the binaries from a specific location and simply 
install/package them.   This is actually the more common approach.

(To seed that location, you can extract the items from your restricted build -- 
or build it outside the tree using an SDK or similar.)

--Mark

> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>