On Tue, 2012-04-03 at 09:13 +0800, Andy Green wrote:
On 04/03/2012 02:58 AM, Somebody in the thread at some point said:
On Mon, 2012-04-02 at 11:18 -0700, John Stultz wrote:
On 04/02/2012 10:29 AM, Jon Medhurst (Tixy) wrote:
On Mon, 2012-04-02 at 08:37 -0700, John Stultz wrote:
On 03/31/2012 02:17 AM, Jon Medhurst (Tixy) wrote:
We almost certainly need board specific android and ubuntu fragments as well, so I'll add vexpress-android.conf and vexpress-ubuntu.conf as well. (Unless there is some magic to have conditional config options in a fragment?)
No, the config fragments are pretty simple, so there's no conditional logic in them. Your idea for a board-type.conf style split sounds like a fair idea. Although, I'm curious what would be an example of this?
There's often let's-just-get-it-working hacks produced, and sometimes you don't want to risk breaking other boards by putting things into a common config.
My example of this is http://android.git.linaro.org/gitweb?p=kernel/vexpress-a9.git%3Ba=commit%3Bh...
Of course, this could be an argument for not enabling such things. ;-)
Ok. Interesting. I can see how this sort of flexibility is useful. So I'm fine if folks want to add board-distro specific tweaks. Trying to find some more unified way of building might be necessary, so folks aren't having to customize things too drastically. Your directory method seems like would solve this, but I need to spend some more time understanding Andy's suggestion and understanding how it works with Andrey's centralized tree.
Possibly if we just had a symlink
configs/omap_5430evm/base/main.conf --> arch/arm/configs/omap_5430evm_defconfigbut then that defconfig has some non board specific stuff, like EXT file-systems configured. And Andrey's Android branch would have TI's Android topics, so that 'base' defconfig file would also gain TI's Android flavourings. (Neither of these issues might be a problem in practice.)
It's really preferable to keep to one defconfig for everything but sometimes that won't be possible (you were saying you might need more than one for presumably very basic reasons).
It depends what more than one defconfig means. I was suggesting that we have multiple fragments so topics could have there own fragment if necessary, for when people don't have stacked topics to modify a single defconfig. I also suggested it might be wise for a get-out-of-jail method so a board could override distro options. (Perhaps the later shouldn't be made part of the normal workflow and instead be a manual hack applied by distro maintainer in exceptional circumstances.)
In that case the config deltas will need to be applied to n defconfigs as part of the rebase / merge process creating the output tree.
So it might be simpler instead of using multiple symlinks if the LT base tree creates and maintains a text file that is a list of "defconfigs this tree maintains" which will all get processed by the topic management scripts in turn for each config delta when the flavourings are added.
I though the distro building would be using merge_config.sh to generate the .config for the build, therefore this would all just be as simple as having it use the argument "my-board-config-directory/*" instead of "my-board-config-file".
For most cases I would guess even "cat my-board-config-directory/*
board.conf" would work. So perhaps we could allow each board to specify
a shell script to generate a config rather than coming up with a mechanism we all agree on? We could also pass the distro as an argument so the script could apply hacks as appropriate.