RFC: Clean up omap3.inc

RFC: Clean up omap3.inc

[Florian Boor]

Hi all,

omap3.inc currently contains this line:

EXTRA_IMAGEDEPENDS += "u-boot x-load"

This makes it hard to build for an OMAP3 based machine without providing a
x-load configuration for it. Actually I do not think hardcoding a particular
bootloader for a class of SoC is a good idea at all. The selection whether a
bootloader needs to be build and which one to select should be a matter of the
machine configuration.

Could we please get rid of this and fix the board descriptions?

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de
                                        http://www.kernelconcepts.de/en

Re: RFC: Clean up omap3.inc

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 10-11-11 21:11, Florian Boor schreef:
> Hi all,
> 
> omap3.inc currently contains this line:
> 
> EXTRA_IMAGEDEPENDS += "u-boot x-load"
> 
> This makes it hard to build for an OMAP3 based machine without providing
> a x-load configuration for it.

Wrong. You can do the following in your machine.conf:

require omap3.inc

EXTRA_IMAGEDEPENDS = "whatever"

to reset it.

> Actually I do not think hardcoding a particular bootloader for a class of
> SoC is a good idea at all. The selection whether a bootloader needs to be
> build and which one to select should be a matter of the machine
> configuration.
> 
> Could we please get rid of this and fix the board descriptions?

In OE classic, no. In meta-ti the cleanup is already underway.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFOvDOVMkyGM64RGpERAunKAKC7udUOfCyn4wLKlPYg5/kMJPSNEgCgqgp9
lFTgVwMfsUQuNuC6mI8VZrg=
=ndzI
-----END PGP SIGNATURE-----

Re: RFC: Clean up omap3.inc

[Florian Boor]

Hi Koen,

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.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de
                                        http://www.kernelconcepts.de/en

Re: RFC: Clean up omap3.inc

[Tom Rini]

On Thu, Nov 10, 2011 at 1:54 PM, Florian Boor
<florian.boor@kernelconcepts.de> wrote:
> Hi Koen,
>
> 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.

-- 
Tom

Re: RFC: Clean up omap3.inc

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

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.

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.


Thanks,

Paul

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: RFC: Clean up omap3.inc

[Tom Rini]

On Sat, Nov 12, 2011 at 3:28 AM, Paul Menzel
<paulepanter@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