Re: Kconfig vs tool chain capabilities

[Jürgen Groß <jgross@xxxxxxxx>]

On 25.08.20 09:34, Jan Beulich wrote:
> On 25.08.2020 09:12, Jürgen Groß wrote:
> > On 25.08.20 08:31, Jan Beulich wrote:
> > > 1) Does it make sense for tool chain capabilities to be recorded?
> > >
> > > 2) Does the recording actually work reliably?
> > >
> > > As to 1), I'm personally of the opinion that the original model
> > > was the better one, even if I can see advantages from downstream
> > > (distro in particular) pov. Yet even for them it may mean they
> > > would not get presented certain options which they may want to
> > > enable, if only they knew they'd need to upgrade their tool
> > > chain. For developers otoh, I don't think this model is a helpful
> > > one: They absolutely should be aware of pieces they end up not
> > > building (and which hence they're also not going test).
> > >
> > > (I'd like to note that there may certainly be cases where during
> > > the building of the tree features get enabled/disabled by other
> > > means without the person doing the build becoming aware. I think
> > > such should equally be converted to Kconfig selections, with the
> > > build simply failing if tool chain prereqs aren't met. The
> > > typical case though is a choice between different ways of
> > > generating code, with no effect on resulting functionality
> > > beyond a possible difference in performance.)
> > >
> > > Additionally the answer to 2) is, I'm afraid, continuing to be
> > > "No", as there is - afaict - no way for a once recorded .config
> > > to get updated if the underlying tool chain changed. All options
> > > to overcome this that I have been able to think of so far
> > > (unconditional invocation of kconfig; hashing of involved [tool
> > > chain] binaries) come with a pretty heavy overhead on build time
> > > and/or other complications.
> > I think both problems can be solved at the same time via the following
> > approach:
> >
> > - collect the data which is reflected in today's CONFIG_ variables in a
> >     single script and store it in a file, e.g in a format like:
> >
> >     CC_IS_GCC y
> >     GCC_VERSION 70500
> >     CLANG_VERSION 0
> >     CC_HAS_VISIBILITY_ATTRIBUTE y
> >
> > - check the tool data at each build to match the contents of that file
> >     and either fail the build or update the file and rerun kconfig if they
> >     don't match (I think failing the build and requiring to run a
> >     "make config" would be the better approach)
> >
> > - fill the CONFIG_ variable contents from that file in kconfig instead
> >     of issuing the single shell commands
> While I agree this is a possible model to use (but still not the
> one we've inherited from Linux), I fail to see how this addresses
> my "developers should be aware of what they do (not) build and
> test" concern: There'd still be dependencies of Kconfig options
> on the tool chain capabilities, and their prompts therefore would
> still be invisible without the tool chain having the needed
> capabilities. IOW I only see this to address 2), but not 1).
Sorry, I fail to see a problem here.

What sense does it make to be able to configure an option which the
tools don't support? Why aren't you concerned that you can't configure
ARM-specific options in an x86 build then?

My model will allow to give the user a hint that something has happened
which will likely have some impact on the hypervisor configuration. It
would even be possible to automatically run "make oldconfig" and print
the resulting diff of .config and .config.old, and maybe even allow the
build to continue if nothing but the tools capabilities/versions have
changed.


Juergen