Re: Kconfig vs tool chain capabilities

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

On 25.08.20 09:43, Jürgen Groß wrote:
> 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.
One other remark:

We can still introduce an config option CONFIG_IGNORE_TOOL_CAPABILITIES
allowing to specify options not supported by the tools.


Juergen