2010/11/3 Khem Raj <[email protected]>: > On Wed, Nov 3, 2010 at 1:17 PM, Tom Rini <[email protected]> wrote: >> Frans Meulenbroeks wrote: >>> >>> 2010/11/3 Tom Rini <[email protected]>: >>>> >>>> Frans Meulenbroeks wrote: >>>>> >>>>> 2010/11/2 Tom Rini <[email protected]>: >>>>>> >>>>>> 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.inc) and thus >>>>>>> when >>>>>>> fixing one BSP you have to think to fix the others (and to communicate >>>>>>> the >>>>>>> fix to other BSP maintainers). >>>>>>> The same apply for most of the .inc in recipes-bsp/*/. >>>>>>> >>>>>>> Do you think the following setup is possible ? >>>>>>> >>>>>>> - ARM overlay (containing all generic files for ARM achitecture : >>>>>>> conf/machines/include for example) >>>>>>> >>>>>>> - OMAP3 overlay (containing all generic files for OMAP3 SOC : >>>>>>> conf/machines/include/omap* + recipes/linux u-boot x-load base files >>>>>>> for >>>>>>> omap3 architecture, >>>>>>> >>>>>>> - specific board overlay (conf/machine/themachine.conf + board >>>>>>> specific >>>>>>> additions in recipes/linux u-boot & x-load (with patches based on top >>>>>>> of >>>>>>> the >>>>>>> OMAP3 overlay). >>>>>> >>>>>> How about: >>>>>> >>>>>> - allow some form of conf/machine/include to continue to exist in the >>>>>> main >>>>>> layer >>>>>> >>>>>> ? There would have to be some judgment calls, but I don't think that >>>>>> should >>>>>> be too hard, over when it's SOC_FAMILY or when it's very generic. >>>>>> Basically >>>>>> the ARM overlay wouldn't be created in this case (nor the PPC nor MIPS >>>>>> nor >>>>>> ...). But we must avoid duplicating tune-coretexa8.inc and similar. >>>>>> >>>>> I'd say it is definitely nice to have a arch specific overlay (e.g. >>>>> ARM, MIPS, PPC, Nios2) which contains the specific recipes for that >>>>> architecture. >>>>> To give an example: >>>>> For nios2 the only backend is for gcc 4.1.2 and binutils >>>>> 17.50.something. I can imagine that at some point in time it is >>>>> decided not to support these in the mainline/standard/common/base >>>>> system. In such a case I think the arch specific overlay would be a >>>>> good place. >>>> >>>> I would argue that so long as someone is maintaining nios2 that means we >>>> can't drop gcc 4.1.2 until there's another stable version for it. And >>>> having that in the nios2 overlay means that it might well start to miss >>>> generic fixes, if we aren't careful. >>>> >>>> Don't get me wrong, I'm quite in favor of breaking things up, and putting >>>> on >>>> my Mentor hat, we have machine specific overlays and like it. >>> >>> I understand you. Problem is that I have been peeking into moving >>> nios2 forward, but the changes in the back end structure between 4.1 >>> and 4.5 are not really minimal, and while I have a basic understanding >>> on compiler internals, I'm by no means a gcc wiz. So guess 4.1.2 for >>> nios will be around for quite a while. >>> And yes, I prefer to keep it on the mainline. as long as possible. >>> Actually I was mostly using this as an example (because I know this one >>> best). > > I dont think it would make sense to put things like gcc and binutils > and core components > into overlays. You stand the risk of out dating these recipes for > developers it would be more focused > to make changes for such things in one place. I will not go into every > overlay and propagate a gcc change to > each one of them thats simply waste of time. Because the change to > core effects all I urge to > practice restrain and not do these kind of things. OE can have recipes > for multiple versions of a given package live together. > As far as machine specific recipes are considered I think its ok > although I would suggest to leverage common stuff as much as can be > done. > 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 misunderstanding and confusion.
FM _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
