On Fri, Nov 27, 2009 at 2:06 PM, Otavio Salvador <[email protected]> wrote: > On Fri, Nov 27, 2009 at 2:25 PM, Ricardo Salveti de Araujo > <[email protected]> wrote: >> On Fri, Nov 27, 2009 at 7:48 AM, Otavio Salvador >>> The changes looks good to me at least. One thing that I'd interesting >>> to know is how are you using the PRODUCT setting and what use cases >>> you've been solving with it. >> >> Cool, thanks for reviewing it. > > No problem; you're welcome. > >> The PRODUCT override came with the need of using Mamona with a common >> machine but for different purposes. Instead of maintaining different >> trees, we decided to create the concept of a product and define there >> the preferred version and providers for different packages. >> >> With this we could work with both "products" at the same tree, just >> using the overrides at the product file to define the best behavior >> for that machine. > > I see. > >> One single example we had was regarding the legal check phase of a >> product, that we knew that some version of some packages was already >> approved, when at the same moment newer versions weren't (so with >> another product that we just started we could use the newer version, >> but for the older one we had keep the same old version, because was >> close to be finished). >> >>> The only cosmetic thing that you might change is to reorder the patch >>> that introduces PRODUCT in bitbake.conf and the distro change to allow >>> for easier understanding of where it come from. >> >> Ok, will change that. Will also change the commit message to explain >> that the idea came from mamona. > > Well but it looks like that to it properly work you need to use one > $TMPDIR for each "product" otherwise if this product has a patch (or > requires one) and the package is already built it won't get it. > > Am I missing anything?
Yep, you're right, you need to do that in order to have a clean build for each product. At mamona we set that while configuring the environment, and in our case we were using a buildbot for each machine, doing always a clean build, so it wasn't actually a problem for us. Cheers, -- Ricardo Salveti de Araujo _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
