2010/7/24 Khem Raj <[email protected]> > On Sat, Jul 24, 2010 at 10:22 AM, Frans Meulenbroeks > <[email protected]> wrote: > > 2010/7/24 Chris Larson <[email protected]> > > > >> On Sat, Jul 24, 2010 at 9:08 AM, Frans Meulenbroeks < > >> [email protected]> wrote: > >> > >> > 2010/7/24 Detlef Vollmann <[email protected]> > >> > > >> > > On 07/24/10 16:35, Frans Meulenbroeks wrote: > >> > > > >> > >> 2010/7/24 Martyn Welch <[email protected]> > >> > >> > >> > >> Can anyone point me to any documentation that describes what > legacy > >> > >>> staging > >> > >>> is and roughly what needs to be done to remove it? > >> > >>> > >> > >> > >> > > > >> > >> There was a post half a year or so ago from Koen, but I can't find > it. > >> > >> Basically it boils down to removing do_stage from a recipe in which > >> case > >> > >> do_install is used to install things in staging > >> > >> in some cases do_install need to be modified to deal with > >> peculiarities > >> > >> that > >> > >> were done in do_stage > >> > >> > >> > >> For native recipes NATIVE_INSTALL_WORKS = "1" may need to be added. > >> > >> > >> > > That's not really much of an explanation. > >> > > Let's take an example. I have two out of tree kernel modules A and > B. > >> > > B depends on A. > >> > > With "legacy" staging, in A_1.0.bb I have a do_install, that copies > >> > > the kernel object, and a do_stage, that copies the header file at > >> > > a place where B_1.0.bb can find it. > >> > > > >> > > How do I do that with non-"legacy" staging? > >> > > > >> > > >> > Apologies if my explanation was too brief. Didn't have too much time > (and > >> > still haven't) > >> > I hope Koen's explanation below helps. > >> > The way I perceive it is that the non-legacy staging is performed by > >> doing > >> > a > >> > do_install with the staging dir as target directory. > >> > Guess someone will correct this if I am wrong. > >> > >> > >> You never touch a staging directory from do_install, ever. You install > >> into > >> the usual paths, relative to ${D}, and the machinery in the classes will > >> automatically populate staging from that. If you need to mangle a file > >> > > > > That is what actually what I wanted to say but apparently failed to > express > > properly > > It is indeed the machinery that does the work, not the user itself. > > > > Frans. > > > >> differently in staging from how you want it in your package, you can > >> install > >> a hook that will be called at staging population time. > >> -- > > > when we are at it may be at the same time look into converting native > recipes > to use BBCLASSEXTEND. In my experience whenever I went to remove legacy > staging I ended up converting the native recipes to use BBCLASSEXTEND along > with >
We still have 400 native recipes. in 270 or so directories > > I have a huge patch where I have removed inherit autotools_staging from > all recipes in OE. I havent tested it so far but should be done in few days > Cool, that would be a great step. > > -Khem > > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
