Re: Kconfig vs tool chain capabilities

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

On 25.08.20 08:31, Jan Beulich wrote:
> Hello,
>
> while the (ongoing) migration to Linux'es Kbuild has brought (and
> will continue to bring) quite a few good improvements, there's one
> aspect that was - afaict - slipped in without any prior mentioning
> and discussing. This mail is meant to serve as a starting point to
> have such a discussion "after the fact". The implication is that I
> expect there to not be an argument along the lines of "is already
> in the tree". In fact one or two of my acks for related patches
> were made dependent upon such a discussion to happen, without a
> preset outcome.
>
> I'd also like to ask to avoid an argument of "Linux is doing so,
> hence we should do so, too". We really ought to form our own
> opinion rather than "blindly" inheriting whatever they do.
>
> The issue is the intended recognition and recording of tool chain
> capabilities. Until now I'm unconvinced this is the intended
> purpose of Kconfig, unlike user land's typical ./configure. The
> latter serves to interrogate the system of available functionality,
> including but not limited to tool chain capabilities. Admin
> overrides to this are possible via --enable*, --disable*, or
> --with* kinds of options handed to the script.
>
> As opposed, Kconfig traditionally has served as merely a tool to
> collect (build) admin decisions, recording them as well as derived
> data. The implication was that the person doing the configuration
> was responsible to ensure that selections requiring special tool
> chain capabilities would be enabled only if the tool chain used
> was actually capable of dealing with the involved code.
>
> Therefore I see two questions that need answering before either
> making more wide spread use of the new functionality, or before
> undoing the present uses and returning back to the original model:
>
> 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


Juergen