[oe] RFC: Clean up omap3.inc

Tom Rini tom.rini at gmail.com
Sat Nov 12 21:21:16 UTC 2011


On Sat, Nov 12, 2011 at 3:28 AM, Paul Menzel
<paulepanter at users.sourceforge.net> wrote:
> Am Donnerstag, den 10.11.2011, 14:55 -0700 schrieb Tom Rini:
>> On Thu, Nov 10, 2011 at 1:54 PM, Florian Boor wrote:
>
>> > Am 10.11.2011 21:27, schrieb Koen Kooi:
>> >> Wrong. You can do the following in your machine.conf:
>> >>
>> >> require omap3.inc
>> >>
>> >> EXTRA_IMAGEDEPENDS = "whatever"
>> >
>> > this is a workaround for a bad misconception. EXTRA_IMAGEDEPENDS could have been
>> > appended everywhere and this intrusive override might break quite a lot.
>> >
>> >> In OE classic, no. In meta-ti the cleanup is already underway.
>> >
>> > I do not care bout meta-ti, its is broken in OE classic.
>> >
>> >
>> > Removing this hardcoded dependency would not break anything. Only the board
>> > maintainers who want to get it built automatically would have to add it.
>>
>> But, that's most of them today.
>
> Sorry Tom, could you try harder to explain the reason, please? How many
> boards are there in the upstream OE repository depending on this and
> would have to be changed? I think Florian could commit that with his
> clean up easily.

With respect to boards that use omap3.inc today, nearly all of them
use x-load as the between ROM and U-Boot program (I suspect
conf/machine/include/palmpre.inc is working around this issue by
setting a fake XLOAD_MACHINE).  So instead of having a few machines
say "now let me not build x-load" we have lots of machines saying "I
should build x-load too".

> On the other side developers opposing this clean up could at least offer
> to add a comment to the file with a proposed work around for people
> hitting this issue. Still there should be a good reason. Like all your
> internal TI projects depend on this for example.

Again, oe.dev isn't a really great place to do new work, oe-core+stuff
is, and as Koen said, in meta-ti this is being cleaned up (in part
because TI parts now don't use x-load as the middle step but a build
of U-Boot called SPL as the middle step).  Adding a comment to
omap3.inc with what Koen said about opting out would make sense, yes.

-- 
Tom




More information about the Openembedded-devel mailing list