Prevent full rebuilds on Kconfig changes

[SebastianBoe]

With Kbuild, a Kconfig change would result in an incremental build. After the CMake migration we get a full rebuild.

Find out if the new performance is acceptable and/or if there exists any low-hanging fruit optimizations that we can take from Kbuild and re-implement in CMake.

[andrewboie]

kbuild had a clever system for enabling this. as I recall, it would create a directory structure for the kconfig space with separate files for each config option, in $OUT/include/config.

[carlescufi]

This will not work with Kconfiglib, due to the fact that it does not generate this tree in kconfig/include/config and kconfig/include/generated at all.

[SebastianBoe]

Until this is resolved I would recommend users that often modify Kconfig in their edit-build-debug cycle to ensure ccache is installed. Otherwise the performance will make the system unusable.

[ulfalizer]

@andrewboie
Yep.

The way it works is that an empty file is stored in include/config/ for each Kconfig symbol, along with a configuration file include/config/auto.conf that records the configuration state during the last build. When rebuilding, .config is compared to auto.conf to see which symbols changed, and the files corresponding to the changed symbols are touched to signal the changes to make. That avoids having to do a full rebuild whenever the configuration is changed.

There also a tool called fixdep that takes care of figuring out what symbols a source file depends on. It basically just greps for CONFIG_* stuff.

It shouldn't be that hard to add the functionality to Kconfiglib, though it requires a bit of work (would need to keep track of the auto.conf values separately from the .config values, etc.). I was thinking that you could have an API that you hand the path to an include/config/ directory, and it would update it (or create it if it doesn't exist) and touch the files for the changed symbols.

[ulfalizer]

Don't know if cmake offers any other options by the way. You'd need some way of recording per-symbol dependencies at least. Just having them as files is natural for make.

[ulfalizer]

Would take less work than I first thought. Could just dump all the current symbol values (e.g. after loading .config files) to a temporary dict, load auto.conf as a normal .config file, compare the new (old) symbol values against the dumped values to see what's different, flag the changes in some appropriate way, and maybe restore the old values. Much simpler in Python than in C. :)

Think it should be pretty trivial now, so I'm happy. Just the cmake end to take care of.

[ulfalizer]

Was a bit trickier than I anticipated (the devil is in the details), but it's implemented now, using the same scheme as the C tools: ulfalizer/Kconfiglib@378dedc

[carlescufi]

@ulfalizer thanks a lot for this! I will rebase to the latest Kconfiglib after the release and we'll see how we can integrate this with CMake.

[SebastianBoe]

re-assigning to me for now, AFAICT the Kconfig part of this is done, and this is now a build-system task.

[carlescufi]

@ulfalizer is this addressed? Can we address it if not?

[ulfalizer]

@carlescufi
Not addressed. The functionality is there in Kconfiglib, but it needs some support outside of it as well, to figure out what symbols each source file depends on.

See the docstring at https://github.com/ulfalizer/Kconfiglib/blob/673f771d2f333b5688d680eba5949f98f12c6177/kconfiglib.py#L1163 for an overview.

The tool that extracts dependencies from source files in the Linux kernel is called fixdep. It's just a kind of fancy grep for CONFIG_* in the source files.

[SebastianBoe]

To implement this one would need to:

Add -MD to the compile_options to have gcc spit out which header
files are used for each source file, which is trivial.

Remove CMake's autodetected dependency on autoconf.h, which I
haven't done before but I hope is possible with CMake.

Run a script on each 'gcc -MD' generated dep file to detect which
symols are used by a source file. Now, this one is tricky, as you
don't know until generation time which source files are going to
be in the build. (The source file list could be in a generator
expression).

In practice this will be difficult to implement and should
therefore be shelved until someone can figure out a simple
solution.

[carlescufi]

@SebastianBoe @ulfalizer did we ever come to a conclusion on this issue?

[ulfalizer]

@SebastianBoe
Linux doesn't bother with gcc -MD when looking for symbols. It just searches the source files directly, and adds a prerequisite like foo: include/config/my/symbol.h if foo.c depends on MY_SYMBOL. Works fine as long as source files don't do stuff like CONFIG_##NAME.

See fixdep.c and the docstring for sync_deps() in Kconfiglib for more details.

[SebastianBoe]

That is interesting. But we can't use fixdep.c because users are not required to have a host C compiler and we don't want to distribute it ourselves.

[SebastianBoe]

There is no way of solving this problem without introducing more complexity than the solution is worth.

So I am closing this as can't-fix.

If someone can figure out a reasonable way to solve this then feel free to comment.