[lkml]   [2017]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL 1/2] Kbuild updates for v4.15
Hi Linus,

2017-11-20 3:02 GMT+09:00 Linus Torvalds <>:
> On Sun, Nov 19, 2017 at 2:40 AM, Masahiro Yamada
> <> wrote:
>>> FWIW, I still think we should probably make the compiler versions etc
>>> available to the configuration management rather than necessarily
>>> cache them.
>> Do you mean something like this?
> Yes. With the important part not being so much that particular syntax,
> but the concept of "get some config options from automation".
> And the most obvious thing to do would be to just initialize a "bool"
> variable by running a script where the end result is either success or
> failure.
> Now, the actual example:
> bool
> option shell="gcc -XYZ"
> is obviously too simplified to be realistic, because it would have to
> account for the actual compiler setup, so what you really need is not
> "just execute a shell command" but the equivalent of the Makefile
> "cc-option" function. Aes, for "known buggy versions" you might want
> to also get the actual compiler version into a config option.
> Even if "cc-option" is the _only_ thing you can do (and not some kind
> of "generic shell escape"), I think that would be very useful.
> Wouldn't it be nice to be able to have all those Makefile things as
> Kcconfig scripts - and be able to very naturally take them into
> account when offering people some Kconfig options?
> So you could do all the logic of not only testing what flags the
> compiler supports, but then use the Kconfig language to _combine_ that
> knowledge with the build options. Both in the sense of "this kernel
> config option depends on the compiler supporting flag XYZ" but also in
> the sense of "the use flag ABC depends on not only compiler support,
> but also on whether the kernel was configured for profiling" or
> whatever.
> Then the actual Makefile parts would be things like
> CFLAGS-$(CONFIG_CC_SPLIT_DWARF) += -gsplit_dwarf
> because the Kconfig phase would already have all the logic for whether
> (a) gcc actually supports -gsplit-dwarf at all and (b) whether the
> user actually asked for split debug info.
> And we'd not have the performance issues that made that whole caching
> thing be an issue, because the actual gcc support testing would only
> happen at Kconfig time.
> .. it would also make the caching rules be obvious. It's just a "if
> you upgraded or changed compilers enough to be noticeable, re-do your
> config ('make oldconfig')".
> Linus

OK, probably this is the right direction.

Embedded folks need to agree to give CROSS_COMPILE to the Kconfig phase.

Best Regards
Masahiro Yamada

 \ /
  Last update: 2017-11-20 16:50    [W:0.043 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site