Re: Kconfig vs tool chain capabilities

[Jan Beulich <jbeulich@xxxxxxxx>]

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).

Jan