Re: Linux 6.3-rc3

From: Kalle Valo <kvalo@kernel.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-toolchains@vger.kernel.org, llvm@lists.linux.dev,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org,
	Nathan Chancellor <nathan@kernel.org>,
	sedat.dilek@gmail.com
Subject: Re: Linux 6.3-rc3
Date: Mon, 27 Mar 2023 20:03:34 +0300	[thread overview]
Message-ID: <87jzz2cejd.fsf@kernel.org> (raw)
In-Reply-To: <87bkke5g31.fsf@intel.com> (Jani Nikula's message of "Mon, 27 Mar 2023 19:12:02 +0300")

Jani Nikula <jani.nikula@linux.intel.com> writes:

> On Sat, 25 Mar 2023, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
>> On Thu, Mar 23, 2023 at 1:56 AM Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>>
>>> On Wed, Mar 22, 2023 at 9:40 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>> >
>>> > You have to pass `make LLVM=1` in any case... to `oldconfig` or when
>>> > adding any MAKEFLAGS like -j${number-of-available-cpus}.
>>>
>>> I actually think we should look (again) at just making the compiler
>>> choice (and the prefix) be a Kconfig option.
>>>
>>> That would simplify *so* many use cases.
>>>
>>> It used to be that gcc was "THE compiler" and anything else was just
>>> an odd toy special case, but that's clearly not true any more.
>>>
>>> So it would be lovely to make the kernel choice a Kconfig choice - so
>>> you'd set it only at config time, and then after that a kernel build
>>> wouldn't need special flags any more, and you'd never need to play
>>> games with GNUmakefile or anything like that.
>>
>>
>> Presumably, this is the right direction.
>>
>> To achieve it, Kconfig needs to have some mechanism to evaluate
>> shell commands dynamically.
>>
>> If a user switches the toolchain set between GCC and LLVM
>> while running the Kconfig, $(cc-option) in Kconfig files must
>> be re-calculated.
>>
>> Currently, Kconfig cannot do it. All macros are static - they are
>> expanded in the parse stage, and become constant strings.
>>
>> Ulf Magnusson and I discussed the dynamic approach a few years back,
>> but I adopted the static way since it is much simpler.
>> We need to reconsider the dynamic approach to do this correctly.
>> I do not think it is too difficult technically.
>> We just need to come up with a decent syntax.
>
> I acknowledge being clueless about mostly everything that requires. But
> in the mean time, how about just adding something like:
>
> -include .env
>
> near the beginning of the top Makefile?
>
> You could shove the tools or ARCH or output dir etc. there, so you don't
> have to remember to add them on the command line every time.

Yes, please! Something like this, but officially supported, would be
just perfect for a lazy person like me.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches