Jeremy Cline schreef op do 10-10-2019 om 09:31 [-0400]:
On Thu, Oct 10, 2019 at 02:20:54PM +0200, Paul Bolle wrote:
> Anyhow, working on this I thought of a way to sort-of do this during
> regular builds. I hope to work on that before v5.5-rc1. Stay tuned!
So I *also* have a vague plan for this (but have not had time to
implement it). The short version of the plan is have a Python script
that walks the kernel Kconfig tree and compares it to our config
snippets to find configurations that no long exist in the kernel and at
the same time find the new configurations and drop them into the correct
arch directories with a default value and the help text. That way the
job of rebasing is also much easier.
How does that line up with your plan?
My "sort-of" is your "vague"!
My current thinking is that it's odd that we generate the .config files in
three steps.
1: the entire configs/fedora/generic/... tree: we update this tree by hand,
basically;
2: the shipped kernel-*.config files: generated by build_configs.sh;
3: the .config files generated by the upstream Kconfig plumbing.
It would be much nicer if of all three would identical. (Which implies the
shipped kernel-*.config files would become superfluous.) And then we could
start by issuing warnings every time the configs/ tree and a generated .config
file get out of sync. (We already do this if we spot new Kconfig values in the
generated .config files. I think in process_configs.sh.)
The hardest part is that current configs/ tree cheats. It makes
# CONFIG_FOO_BAR is not set
also apply for the situation that CONFIG_FOO_BAR is invisible (or whatever the
proper Kconfig jargon is here). I need to play with my idea to see how
invisible Kconfig macros could be handled without cheating.
The next step might be something like your automation. That looks hard,
though!
Does the above make sense?
Paul Bolle