On 02/08/2017 07:50 PM, Chris Brandt wrote: > Hello Florian, > > On Wednesday, February 08, 2017, Florian Fainelli wrote: >> On 02/08/2017 07:30 PM, Chris Brandt wrote: >>> Creates a new ARM_SINGLE_ARMV7 option as an alternative >> ARCH_MULTIPLATFORM. >>> >>> ARM_SINGLE_ARMV7 is very similar to ARCH_MULTIPLATFORM, except the >>> options from ARCH_MULTI_V6_V7 were copied directly into the new >> ARM_SINGLE_ARMV7. >>> >>> Additionally, everywhere ARCH_MULTIPLATFORM existed in build scripts, >>> ARM_SINGLE_ARMV7 was added along side it in order to produce similar >>> results. >> >> Could we try to be a little smarter than this and if ARCH_MULTIPLATFORM is >> selected but only one platform beneath is we automatically select >> ARM_SINGLE_ARMV7 (this may require Kconfig hackery)? > > Months ago I spent hours on trying to get the current kbuild system to do > that and nothing I came up with would work. It's simply not designed that > way. > > I think the closest I might have come was to purposely break the build > if more then 1 was select, but that still didn't stop you from making > the selection. > > If someone smarter than me has a way to do (not just an idea...I received > lots of ideas but none of them worked), I'd be happy to hear it. I am definitively not a Kbuild expert, but it would almost necessarily require introduce some kind of new type in the Kconfig/Kbuild syntax that does something like that: - have a way to count the number of symbols that are selected and do a "if ARCH_MULTI_V6_V7" (or an arbitrary expression) this most likely should exist internally within Kconfig - introduce a new type of Kconfig type which is a "count", and gets assigned this value that we just counted, something that could look like this: count ARCH_MULTI_V6_V7_COUNT tracks ARCH_MULTI_V6_V7 All other typical Kconfig syntax thould then still apply and we could be doing something like: depends on ARCH_MULTI_V6_V7_COUNT=1 etc.. So yeah, I am no better than whoever gave you indications better ;) > > > >> I see value in what you are doing, but I don't think pulling the platforms >> out of the menu like what you do in the subsequent patch is looking nice >> as an user/configurator. > > What I was trying to do (and what was already removed from Kconfigs) was > to avoid having a duplicate set of configs for each SOC: one for single and > one for multi. > > > #I'm trying to get away from manually hacking these Kconfig files every time > a new kernel is released. Sure, that makes complete sense to me. FWIW, there is one particular case that I am interested that you solved which is allowing DEBUG_UNCOMPRESS to be set in our downstream kernel because we typically only enable BRCMSTB and nothing else. -- Florian
