[U-Boot] Python subprocess module missing in multiconfig.py

[Jeroen Hofstee <dasuboot@myspectrum.nl>]

Hello Marek,

On 07-08-14 23:52, Marek Vasut wrote:
> <small>
> Thanks for CCing me.
>
> I sent a patch to OE-core to ship the python modules. This is a problem
> with the Yocto Qt SDK toolchain in general and you can track the mayhem
> at [1]. There will likely be ELDK 5.5.3 once this is all settled.
>
> btw. you should update to ELDK 5.5.2 in the first place, since the
> compiler in Yocto 1.5.0 did have trouble with code generation [2], [3].
>
> [1] http://lists.openembedded.org/pipermail/openembedded-core/2014-
> August/095470.html
> [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
> [3]http://lists.openembedded.org/pipermail/openembedded-core/2014-
> February/089489.html
>> A bit of topic, beside the toolchain problems, aren't these
>> dependencies of the u-boot recipe? The native sdk will pick
>> them up if any machine needs them (at least in my setup).
> Why would it do it please?

For the RDEPENDS at least adding it to the recipe itself instead of some
common image file makes sure it gets deleted if nobody is using it any
longer. And hopefully makes sure you can't compile/use something on the
host which isn't on the target, since the header files will be missing.
RDEPENDS do get included in the sdk in my setup. For DEPENDS it would
mean the sdk can build the same targets with the same tools, but I never
checked if it does that.

> What exactly is your setup, please describe it in detail.

Doesn't really matter, you need to convince the oe people. Not me,
I am just a user of oe user, if the thing does what I want I am happy
enough.

>
>> Besides of that, do we really want so much dependencies
>> for u-boot what used to be sed, awk.. and uh find perhaps?
>> Is all of this needed to just compile u-boot?
> This is a question for Yamada-san, +CC . But from my point of view, I see we had
> dependency on python with some tools for a while -- it's only now that the
> dependency got pulled into the build system. On the other hand, I don't know
> what are the plans with the Kconfig and it might end up that this dependency
> will eventually disappear.
>

yup, understood, I will leave it up to them.

With kind regards,
Jeroen