Re: Kconfig vs tool chain capabilities

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.08.2020 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:
>>> 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?

Take CET as an example (chosen because that's the one which
already uses the Kconfig approach, despite my disagreement): It's
quite relevant to know whether you're testing Xen with it enabled,
or with it disabled (and hence you potentially missing changes you
need to make to relevant code portions).

> Why aren't you concerned that you can't configure
> ARM-specific options in an x86 build then?

I can't see how this is related.

Jan