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;a=commit;h=20a2abd40fff4d5942263c09b9852986c47aaa32 > >>> > >>> 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_defconfig > > > > but 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. -- Tixy _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
