On 2/24/12 04:55 , Richard Purdie wrote:
Someone recently asked me about using external source trees with OE-Core. [...] Opinions on including this class?
I see value.
Our workflow, (based on an ancient branch of oe), uses something similar. When working on a component in context, (as distinct from standalone), the developer sets S to point to his own directory and then just avoids the tasks with awkward side effects like clean and mrproper.
We had problems initially with people committing bb files with S still pointed to the local values. There needs to be a safety catch for this somewhere as this mistake is too easy to make and affects everyone when it happens.
Against my better judgment, someone locally implemented a ~/oe.conf arrangement that developers now use to override S for the components in which they work. That seems to have largely addressed the problem of accidental commits of bb files with bad S values, but has opened a completely different set of problems, of course. I don't think this is the right solution to the accidental commit problem, but I think some sanity check or "best practice" for overriding S is required before including this class.
--rich _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
