Hi Masahiro, On Sun, 16 Feb 2020 13:57:59 -0500 Jeremy Cline <jcline@xxxxxxxxxx> wrote: > On Sun, Feb 16, 2020 at 01:08:49PM +0900, Masahiro Yamada wrote: > > On Sat, Feb 15, 2020 at 5:35 AM Jeremy Cline <jcline@xxxxxxxxxx> wrote: > > > > > > On Fri, Feb 14, 2020 at 12:31:05PM +0900, Masahiro Yamada wrote: > > > > Hi. > > > > > > > > On Tue, Feb 11, 2020 at 3:49 AM Philipp Rudo <prudo@xxxxxxxxxxxxx> wrote: [...] > > > > One idea to workaround this is > > > > to use a fake script that accepts any flag, > > > > and use it as $(CC) in Kconfig. > > > > > > > > RFC patch is attached. > > > > > > > > This is not a perfect solution, of course. I like the approach as it gives both sides what they need without blowing up Kconfig. > > > The attached patch doesn't looks like it'd work for what we need, > > > > I thought turning all cc-options to y would work > > for what you need. > > > > With this, you can enable > > CONFIG_MARCH_Z13=y and CONFIG_TUNE_Z14=y > > instead of CONFIG_TUNE_DEFAULT. > > > > If this approach does not work for you, > > what is your requirement? > > > > Oof, this was an awful typo. It *would* work for what we need. Sorry for > the confusion :(. > > > > > > > > although I wonder if it's easier to just check when cc-options is > > > defined for an environment variable or something and always return y > > > instead of calling out to $(CC) at all. Comes to the same thing, I > > > suppose. > > > > > > The macro definition in scripts/Kconfig.include > > takes precedence over any environment variable. > > > > So, if you want to hack it from the environment, > > you need to change the code somehow. > > > > The scripts/dummy-tools/ approach does not change > > anything for the use-case in upstream. > > > > The result is the same, of course. > > > > Indeed. Since I'm not maintaining it I don't have a particularly strong > opinion about the approach. Whatever you like most works for me. I agree with Jeremy. Just pick what you think is best. Thanks a lot Philipp
