On Mon, 2019-12-02 at 15:27 -0800, Alejandro Enedino Hernandez
Samaniego wrote:
> So I have tried something similar to this, and while it does work,
> due to some parsing issue (I still have not figured out exactly what)
> the multiconfig dependencies between multiconfigs are not being taken
> into account, which defeats the whole purpose.
It likely makes sense to understand why its breaking since wouldn't
those issues affect this regardless of which direction things go in?
> While I understand that introducing a new variable might create some
> confusion, at the same time I do believe that it would be
> better if we do it that way, and in some way separate workflows when
> we are building a "full" heterogeneous system vs a single
> architecture system, the difference lies in the fact that we dont set
> what the "master" or core MACHINE is, they are all equal.
>
> I have been working on the implementation of this proposal and here
> is what I currently have for which of course I am open to change.
>
> Like I said, I had issues with defining a placeholder machine for the
> multiconfig dependencies, so I did go with defining
>
> SYSTEM = "dummy-system"
>
> on local.conf (also not a huge fan of the name since to me its a bit
> too generic,but as RP said, the name is probably the least of our
> problems)
>
> then
> include conf/system/${SYSTEM}.conf
>
> and I have the following set up on a layer:
>
> meta-heterogeneous
> conf/layer.conf
> conf/system/dummy-system.conf
> conf/multiconfig/dummy-arm64.conf
> conf/multiconfig/dummy-x86-64.conf
> recipes-heterogeneous/heterogeneous-example_1.0.bb
>
> Explanation:
> layer.conf - normal layer.conf, nothing out of the ordinary
> dummy-system.conf - Defines BBMULTICONFIG as dummy-arm64 and dummy-
> x86-64, AND defines the multiconfig dependencies between them
> dummy-*64.conf - Define each of the multiconfigs, in them there are
> only 3 variables, DISTRO, MACHINE (qemuarm64 and qemux86-64
> respectively), and TMPDIR which is simpy defined as tmp-${MACHINE}
> heterogeneous-example_1.0.bb : This was a placeholder recipe, since
> to my knowledge bitbake required a target, and it simply contained a
> line that set up a multiconfig dependency that would allow:
>
> $ bitbake heterogeneous-example
I'm going to try and make a concise reply to both you and Mark.
What worries me is that in this "dummy-system" context there is only
one valid recipe which is the heterogeneous-example, everything else is
meaningless.
If we go this route we'll start having to add special corner casing for
"nomachine" and "notune" and everywhere, then special case those values
since there is code they will need to pass through. I don't think these
concepts make sense to the majority of users and I think the damage
we'd do to the metadata trying to retrofit them will be significant and
not in the interests of the project.
Looking at things a different way, the proposal makes little difference
to adding a new machine above called "dummy-system" which sets up the
multiconfigs, it just gives it a different name, SYSTEM instead of
MACHINE. I think you can achieve much of (all?) the same things with a
naming convention rather than needing a new namespace. If multiconfig
has bugs with that, we should fix them?
Cheers,
Richard
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
