-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Recipes/linux is a mess and recipes/u-boot is as well. It would be a
nice topic for OEDEM to see if we discuss switching to a poky BSP model.
It would boil down to:
1 base bblayer with shared files:
* conf/machine/include
* recipes/linux/*.inc
1
On 21/10/2010 10:33, Koen Kooi wrote:
> Hi,
>
> Recipes/linux is a mess and recipes/u-boot is as well. It would be a
> nice topic for OEDEM to see if we discuss switching to a poky BSP model.
> It would boil down to:
>
> 1 base bblayer with shared files:
> * conf/machine/include
> * recipes/linux/*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 21-10-10 11:52, Graeme Gregory wrote:
> On 21/10/2010 10:33, Koen Kooi wrote:
>> Hi,
>>
>> Recipes/linux is a mess and recipes/u-boot is as well. It would be a
>> nice topic for OEDEM to see if we discuss switching to a poky BSP model.
>> It would b
On 21/10/2010 10:59, Koen Kooi wrote:
> On 21-10-10 11:52, Graeme Gregory wrote:
> > On 21/10/2010 10:33, Koen Kooi wrote:
> >> Hi,
> >>
> >> Recipes/linux is a mess and recipes/u-boot is as well. It would be a
> >> nice topic for OEDEM to see if we discuss switching to a poky BSP
> model.
> >> It
Some initial thoughts:
What about out-of-tree kernel modules?
No idea right away whether we have many.
I can imagine we want to keep these in one place (I doubt if they are
very machine specific).
putting the recipes in the overlay creates some duplication (and hence
potentially double maintenanc
2010/10/21 Graeme Gregory :
>>
> Such a pity git doesnt have increasing rev numbers, a cool adition would
> be a flag in layer that showed the last rev of core it was tested with.
>
> Layer was tested with core 1 but core is now 999 would give an
> indication on drift between layers and core.
>
>
On Thu, 2010-10-21 at 11:33 +0200, Koen Kooi wrote:
> Recipes/linux is a mess and recipes/u-boot is as well. It would be a
> nice topic for OEDEM to see if we discuss switching to a poky BSP model.
> It would boil down to:
>
> 1 base bblayer with shared files:
> * conf/machine/include
> * recipes/
On Thu, 2010-10-21 at 12:20 +0200, Frans Meulenbroeks wrote:
> 2010/10/21 Graeme Gregory :
>
> >>
> > Such a pity git doesnt have increasing rev numbers, a cool adition would
> > be a flag in layer that showed the last rev of core it was tested with.
> >
> > Layer was tested with core 1 but core i
On Thu, 2010-10-21 at 11:59 +0200, Koen Kooi wrote:
> The downside of amend.inc is the de-sync when the recipe gets updated,
> but not the overlay. You run the risk of using a version without the
> overrides that way.
> Maybe some fancy scripts, (pre-)commit hooks or just old fanishioned
> review o
On 21/10/2010 11:48, Richard Purdie wrote:
> On Thu, 2010-10-21 at 11:59 +0200, Koen Kooi wrote:
>> The downside of amend.inc is the de-sync when the recipe gets updated,
>> but not the overlay. You run the risk of using a version without the
>> overrides that way.
>> Maybe some fancy scripts, (pre
2010/10/21 Richard Purdie :
> On Thu, 2010-10-21 at 12:20 +0200, Frans Meulenbroeks wrote:
>> 2010/10/21 Graeme Gregory :
>>
>> >>
>> > Such a pity git doesnt have increasing rev numbers, a cool adition would
>> > be a flag in layer that showed the last rev of core it was tested with.
>> >
>> > Lay
ubject: Re: [oe] [RFC] turning conf/machine into a set of bblayers
>
> 2010/10/21 Richard Purdie :
> > On Thu, 2010-10-21 at 12:20 +0200, Frans Meulenbroeks wrote:
> >> 2010/10/21 Graeme Gregory :
> >>
> >> >>
> >> > Such a pity git doesnt
On Thu, Oct 21, 2010 at 2:59 AM, Koen Kooi wrote:
> The downside of amend.inc is the de-sync when the recipe gets updated,
> but not the overlay. You run the risk of using a version without the
> overrides that way.
> Maybe some fancy scripts, (pre-)commit hooks or just old fanishioned
> review on
On Thu, Oct 21, 2010 at 6:46 AM, Maupin, Chase wrote:
> I haven't tried this myself yet, but if you wanted to tie to a particular
> PR of the base recipe wouldn't you just put the amend.inc in your overlay at
> recipes/blah/blah-version-pr directory?
Yes, but bbappend can't do that, its bound t
On Thu, Oct 21, 2010 at 07:21:49AM -0700, Chris Larson wrote:
> On Thu, Oct 21, 2010 at 6:46 AM, Maupin, Chase wrote:
>
> > I haven't tried this myself yet, but if you wanted to tie to a particular
> > PR of the base recipe wouldn't you just put the amend.inc in your overlay at
> > recipes/blah/b
Frans Meulenbroeks wrote:
2010/10/21 Graeme Gregory :
Such a pity git doesnt have increasing rev numbers, a cool adition would
be a flag in layer that showed the last rev of core it was tested with.
Layer was tested with core 1 but core is now 999 would give an
indication on drift between laye
2010/10/21 Koen Kooi :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Recipes/linux is a mess and recipes/u-boot is as well. It would be a
> nice topic for OEDEM to see if we discuss switching to a poky BSP model.
> It would boil down to:
>
> 1 base bblayer with shared files:
> * con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02-11-10 08:02, Frans Meulenbroeks wrote:
> 2010/10/21 Koen Kooi :
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi,
>>
>> Recipes/linux is a mess and recipes/u-boot is as well. It would be a
>> nice topic for OEDEM to see if we discuss
Hi,
Le 02/11/2010 21:46, Koen Kooi a écrit :
I do fear that pulling things into seperate layers too much will make it
harder to propagate fixes...
yes, in your example, the fines in conf/machine/include are common to all omap
boards (and even all cortexa8 for tune-cortexa8.inc) and thus when f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02-11-10 22:14, Eric Bénard wrote:
> Hi,
>
> Le 02/11/2010 21:46, Koen Kooi a écrit :
>> I do fear that pulling things into seperate layers too much will make it
>> harder to propagate fixes...
>>
> yes, in your example, the fines in conf/machine/i
Eric Bénard wrote:
Hi,
Le 02/11/2010 21:46, Koen Kooi a écrit :
I do fear that pulling things into seperate layers too much will make it
harder to propagate fixes...
yes, in your example, the fines in conf/machine/include are common to
all omap boards (and even all cortexa8 for tune-cortexa8.
On Tue, Nov 2, 2010 at 1:46 PM, Koen Kooi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02-11-10 08:02, Frans Meulenbroeks wrote:
>> 2010/10/21 Koen Kooi :
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Hi,
>>>
>>> Recipes/linux is a mess and recipes/u-boot is as w
2010/11/2 Tom Rini :
> Eric Bénard wrote:
>>
>> Hi,
>>
>> Le 02/11/2010 21:46, Koen Kooi a écrit :
>>>
>>> I do fear that pulling things into seperate layers too much will make it
>>> harder to propagate fixes...
>>>
>> yes, in your example, the fines in conf/machine/include are common to all
>> om
Frans Meulenbroeks wrote:
2010/11/2 Tom Rini :
Eric Bénard wrote:
Hi,
Le 02/11/2010 21:46, Koen Kooi a écrit :
I do fear that pulling things into seperate layers too much will make it
harder to propagate fixes...
yes, in your example, the fines in conf/machine/include are common to all
omap
2010/11/3 Tom Rini :
> Frans Meulenbroeks wrote:
>>
>> 2010/11/2 Tom Rini :
>>>
>>> Eric Bénard wrote:
Hi,
Le 02/11/2010 21:46, Koen Kooi a écrit :
>
> I do fear that pulling things into seperate layers too much will make
> it
> harder to propagate fixes...
>
Frans Meulenbroeks wrote:
2010/11/3 Tom Rini :
Frans Meulenbroeks wrote:
2010/11/2 Tom Rini :
Eric Bénard wrote:
Hi,
Le 02/11/2010 21:46, Koen Kooi a écrit :
I do fear that pulling things into seperate layers too much will make
it
harder to propagate fixes...
yes, in your example, the fin
On Wed, Nov 3, 2010 at 1:17 PM, Tom Rini wrote:
> Frans Meulenbroeks wrote:
>>
>> 2010/11/3 Tom Rini :
>>>
>>> Frans Meulenbroeks wrote:
2010/11/2 Tom Rini :
>
> Eric Bénard wrote:
>>
>> Hi,
>>
>> Le 02/11/2010 21:46, Koen Kooi a écrit :
>>>
>>> I do fear
2010/11/3 Khem Raj :
> On Wed, Nov 3, 2010 at 1:17 PM, Tom Rini wrote:
>> Frans Meulenbroeks wrote:
>>>
>>> 2010/11/3 Tom Rini :
Frans Meulenbroeks wrote:
>
> 2010/11/2 Tom Rini :
>>
>> Eric Bénard wrote:
>>>
>>> Hi,
>>>
>>> Le 02/11/2010 21:46, Koen Kooi
>>
> I'm not planning to.
> This would be the solution if for one reason or another gcc 4.1.2 was
> kicked from the base layers (or the associated binutils).
> I have a very strong preference ot keep them in the base layer.
> This was only intended as an example.
> Apologies for the misunderstandin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03-11-10 21:44, Khem Raj wrote:
> I dont think it would make sense to put things like gcc and binutils
> and core components
> into overlays.
I would put those into a 'devtools' layer, like poky has done.
regards,
Koen
-BEGIN PGP SIGNATURE--
30 matches
Mail list logo
