From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [80.91.229.12] (helo=lo.gmane.org) by linuxtogo.org with esmtp (Exim 4.69) (envelope-from ) id 1N4yht-0008IA-2y for openembedded-devel@lists.openembedded.org; Mon, 02 Nov 2009 16:20:36 +0100 Received: from list by lo.gmane.org with local (Exim 4.50) id 1N4ygi-0005sE-AA for openembedded-devel@lists.openembedded.org; Mon, 02 Nov 2009 16:19:20 +0100 Received: from s55917625.adsl.wanadoo.nl ([85.145.118.37]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Nov 2009 16:19:20 +0100 Received: from k.kooi by s55917625.adsl.wanadoo.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Nov 2009 16:19:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: openembedded-devel@lists.openembedded.org From: Koen Kooi Date: Mon, 02 Nov 2009 16:18:57 +0100 Message-ID: References: <1257169407.11338.71.camel@dax.rpnet.com> <1257174010.11338.81.camel@dax.rpnet.com> Mime-Version: 1.0 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: s55917625.adsl.wanadoo.nl User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3pre) Gecko/20090811 Shredder/3.0b4pre In-Reply-To: <1257174010.11338.81.camel@dax.rpnet.com> Sender: news X-SA-Exim-Connect-IP: 80.91.229.12 X-SA-Exim-Mail-From: gcho-openembedded-devel@m.gmane.org X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:20:07 +0000) X-SA-Exim-Scanned: No (on linuxtogo.org); Unknown failure Subject: Re: Staging - time to end the current mess? X-BeenThere: openembedded-devel@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: openembedded-devel@lists.openembedded.org List-Id: Using the OpenEmbedded metadata to build Distributions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 15:20:36 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02-11-09 16:00, Richard Purdie wrote: > On Mon, 2009-11-02 at 15:29 +0100, Koen Kooi wrote: >> On 02-11-09 14:43, Richard Purdie wrote: >>> At OEDEM two years ago I proposed radically altering the way staging >>> worked. For those that don't remember the bad old days, the staging >>> directory layout didn't match that of the target file system meaning >>> every recipe needed a custom do_stage and things were a mess. >>> >>> We changed the layout allowing the use of the gcc/binutils sysroot >>> options and also started widespread use of autotools_stage_all and I'd >>> say things look much improved compared to how they were. >>> >>> Anyone who has looked at the packaged-staging code will probably agree >>> there is still a way to go though - its horrendously complicated. We >>> also do a lot of duplication. I'd like to propose a new simple way of >>> doing things. We'd have the following work flow: >>> >>> >>> [...] >>> do_compile - up to here all as usual >>> do_install - Everything installs into a DESTDIR (including -native) >>> do_package - Takes a copy of the DESTDIR, applies any .la/.pc mangling >>> then splits into packages as usual >>> do_populate_staging - Takes a copy of the DESTDIR, mangles, installs >>> into staging and creates staging packages from this >>> >>> Firstly, does any disagree with this approach or can we all agree its a >>> nice objective? >> >> Can we make the mangling a seperate tasks? I tend to do the mangling in >> do_compile_append to be able to do builds *on* the target as well. > > I just published my WIP tree: > > http://cgit.openembedded.net/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress > > and specifically: > > http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=rpurdie/work-in-progress&id=1d69a38be629a70faf65dd9f2e9db12164071bfd > > which means we'd start declaring "mangling" functions in their own > right. Does that work for you? That was exactly what I was thinking about :) > Where we run these is then up to the core metadata so we can attach them > to stage/install/compile as makes sense. I want to declare some > conventions of the directories these operate on so we can make the > functions "relocatable" by changing the input variables. > >> And >> >> * 'make install' doesn't actually work properly for lots of packages >> (you know, the ones with handcrafted makefiles) >> >> But we can solve that by putting the custom do_stage() methods for those >> in do_install(), right? > > Those packages will already have a custom do_install in some directory > so we can just use them as is. My biggest fear is these kind of recipes: do_install() { oe_libinstall foo ${D} } do_stage() } oe_libinstall foo ${D} cp foo.h ${STAGING_INC_DIR} } I guess we could grep for do_stage_{ap,pre}pend to find the worst offenders and gradually fix up remaining offenders. regards, Koen