On 04/02/2012 09:40 PM, Somebody in the thread at some point said:
On Mon, 2012-04-02 at 21:10 +0800, Andy Green wrote:
If you want to do it with this complex directory scheme, please don't so anything to the definitive sources that makes it mandatory.
Just so I understand properly, are you saying that for the TI kernels you want to just supply a single fully featured defconfig file and have that used to produce builds, rather than having one built up from OMAP bits supplied by you and other android/ubuntu/linaro bits obtained from another source?
Not at all.
I don't want to sound like a broken record but we have been doing this layered config stuff for a long time. It's a very good wheeze and centralizing some of it will give good results if we can do it in a good way.
Here's an example from our repo.
Currently our vanilla tree ends at
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...
that's made up of many topics each of which add to the single defconfig omap_5430evm_defconfig so it builds and configures for the topic content. At this end point, it has all the topic patches in and all the topic config enabled.
An example of what we have been talking about can be found at the "flavour" branch lat-3.3.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...
This is based on the vanilla tree from tracking-topic-omapdrm, it contains the generic androidization patches.
At the end of lat-3.3, I have a patch "config OMAP5 Android" which adapts the single defconfig that came in from vanilla, omap_5430evm_defconfig, to have generic Androidization options
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=commi...
So when you check out lat-3.3 or one of the tags pointing at it, you get always up-to-date, androidized, omap4+omap5 defconfig with the same name as vanilla.
The defconfig you check out at the vanilla tree back at tracking-topic-omapdrm doesn't have to know or take care or be affected by any of that.
When it's available and we're able to, we'll also start putting out a new flavour branch which has linux-linaro-tracking "flavoured" on to it, and just like in lat-3.3 case we will modify the vanilla defconfig according to what that flavour needs.
All we require is that the flavour tree, be it linux-androidization-tracking, or linux-linaro-tracking, comes with a patch containing the defconfig delta that's meaningful for it.
If that makes sense, you can see there's no need for directory structures, the various flavour and result trees can contain all the deltas and variant defconfigs.
-Andy