Hi!
On Fri, Apr 20, 2018 at 10:59 AM, Iván Castell <icast...@nayarsystems.com>
wrote:
> We are trying to use yocto in a continuous integration environment with
> different (production vs debug) scenarios.
>
> To setup a given scenario (production vs debug) we are using something like
> this:
>
> $ SCENARIO=debug
> $ MACHINE=<machine> DISTRO=<distro>-${SCENARIO} source
> ../../build-<machine>-${SCENARIO}
> $ bitbake <image>-${SCENARIO}
>
> So we have different image recipes:
>
> * image-production.bb
> * image-debug.bb
>
> Different distros:
>
> * distro-production.conf
> * distro-debug.conf
>
> And different build directories:
>
> * build-<machine>-production
> * build-<machine>-debug
>
> To optimize space usage and compilation time, we setup a shared sstate
> cache and a shared directory for downloads. This seems a good starting
> point.
Shared download, yes.
But can you share state between distros? Isn't the purpose of distros to
use different options (variable settings) so the state would always be
different?
(Please note: This is really a follow-up question, not me knowing
better. I am just trying to fully understand these concepts)
> However, things are getting complicated, because there is no way to
> exclude some recipes easily. For example, we don't want iptables
> installed on the debug image, but dependency chains include iptables
> by default
Doesn't blacklist do what you want?
E.g. in your distro-production.conf
PNBLACKLIST[iptables] = "we don't want iptables in product"
Of course if something has a hard dependency on iptables, the something
might need blacklisting instead or too.
Regards,
Uwe Geuder
Neuro Event Labs Oy
Tampere, Finland
uwe.gex...@neuroeventlabs.com (Bot check: fix one obvious typo)
> even when declaring IMAGE_INSTALL_remove explicitly. In this case we
> decided checking _%.bbappend to decide what rules are installed on ion
> vs rules.debug).
>
> hod is poisoning all our recipes with that kind of
>
>
> right way to manage this? Can you suggest a
> ay to deal with this?
>
>
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
