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
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
