Hi Geert/Masahiro.
On Fri, May 10, 2019 at 08:46:35AM +0200, Geert Uytterhoeven wrote:
> Hi Yamada-san,
>
> On Fri, May 10, 2019 at 8:14 AM Masahiro Yamada
> <yamada.masahiro@xxxxxxxxxxxxx> wrote:
> > Kconfig updates the .config when it exits even if its content is
> > exactly the same as before. Since its timestamp becomes newer than
> > that of other build artifacts, additional processing is invoked,
> > which is annoying.
> >
> > - syncconfig is invoked to update include/config/auto.conf, etc.
> >
> > - kernel/config.o is recompiled if CONFIG_IKCONFIG is enabled,
> > then vmlinux is relinked as well.
> >
> > If the .config is not changed at all, we do not have to even
> > touch it. Just bail out showing "No change to .config".
It would be preferable that if nothing changed no output is generated.
Like we do not tell that we did not build a .o file because the .c file
had not changed.
Less noise for a kernel build where nothings happens.
> This causes a semantic change for the meaning of ".config.old", which is
> no longer updated if .config has not changed.
> Hence its contents may no longer correspond to the previous config, but to
> an arbitrary older version.
This semantic change is good.
So we now have a .config.old that correspond to the state before
the last change. Also after several kernel builds.
> > My workflow involves always running my own script "linux-oldconfig",
> instead of "make oldconfig", so I immediately see what has changed:
>
> $ cat $(type -p linux-oldconfig)
> #!/bin/bash
> make ${0#*/linux-} && colordiff -u .config{.old,}
So scripts relying on the old (broken) behaviour will no longer work.
The new behaviour is better as it is usefaul in many typical situations.
Hacking, hack. What did I change in the config?
Sam
