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
WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@kernel.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Masahiro Yamada <masahiroy@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>,
linux-toolchains@vger.kernel.org, sedat.dilek@gmail.com,
Linus Torvalds <torvalds@linux-foundation.org>
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
next prev parent reply other threads:[~2023-03-27 17:05 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-19 20:50 Linux 6.3-rc3 Linus Torvalds
2023-03-20 8:21 ` Build regressions/improvements in v6.3-rc3 Geert Uytterhoeven
2023-03-21 5:38 ` Build regressions/improvements in v6.3-rc3 (drm/msm/) Randy Dunlap
2023-03-21 5:38 ` Randy Dunlap
2023-03-21 7:34 ` Geert Uytterhoeven
2023-03-21 7:34 ` Geert Uytterhoeven
2023-03-21 15:10 ` Randy Dunlap
2023-03-21 15:10 ` Randy Dunlap
2023-03-21 15:33 ` Geert Uytterhoeven
2023-03-21 15:33 ` Geert Uytterhoeven
2023-03-20 18:05 ` Linux 6.3-rc3 Nathan Chancellor
2023-03-20 18:05 ` Nathan Chancellor
2023-03-20 18:26 ` Linus Torvalds
2023-03-20 18:26 ` Linus Torvalds
2023-03-20 18:49 ` Linus Torvalds
2023-03-20 18:49 ` Linus Torvalds
2023-03-20 18:56 ` Nathan Chancellor
2023-03-20 18:56 ` Nathan Chancellor
2023-03-20 19:05 ` Linus Torvalds
2023-03-20 19:05 ` Linus Torvalds
2023-03-20 18:53 ` Nathan Chancellor
2023-03-20 18:53 ` Nathan Chancellor
2023-03-20 19:22 ` Nathan Chancellor
2023-03-20 19:22 ` Nathan Chancellor
2023-03-22 12:44 ` Kalle Valo
2023-03-22 12:44 ` Kalle Valo
2023-03-22 16:36 ` Nathan Chancellor
2023-03-22 16:36 ` Nathan Chancellor
2023-03-22 20:36 ` Nathan Chancellor
2023-03-22 20:36 ` Nathan Chancellor
2023-03-24 10:54 ` Kalle Valo
2023-03-24 10:54 ` Kalle Valo
2023-03-24 15:11 ` Nathan Chancellor
2023-03-24 15:11 ` Nathan Chancellor
2023-03-24 15:23 ` Kalle Valo
2023-03-24 15:23 ` Kalle Valo
2023-03-28 19:07 ` Nathan Chancellor
2023-03-28 19:07 ` Nathan Chancellor
2023-03-29 8:39 ` Kalle Valo
2023-03-29 8:39 ` Kalle Valo
2023-03-22 16:40 ` Sedat Dilek
2023-03-22 16:40 ` Sedat Dilek
2023-03-22 16:55 ` Linus Torvalds
2023-03-22 16:55 ` Linus Torvalds
2023-03-22 18:17 ` Nick Desaulniers
2023-03-22 18:17 ` Nick Desaulniers
2023-03-24 17:16 ` Masahiro Yamada
2023-03-24 17:16 ` Masahiro Yamada
2023-03-27 16:12 ` Jani Nikula
2023-03-27 16:12 ` Jani Nikula
2023-03-27 17:03 ` Kalle Valo [this message]
2023-03-27 17:03 ` Kalle Valo
2023-03-20 20:04 ` Guenter Roeck
2023-03-20 20:04 ` Guenter Roeck
2023-03-20 20:30 ` Linus Torvalds
2023-03-20 20:30 ` Linus Torvalds
2023-03-20 22:06 ` Nathan Chancellor
2023-03-20 22:06 ` Nathan Chancellor
2023-03-20 22:48 ` Segher Boessenkool
2023-03-20 22:48 ` Segher Boessenkool
2023-03-20 23:41 ` Linus Torvalds
2023-03-20 23:41 ` Linus Torvalds
2023-03-24 9:41 ` Daniel Vetter
2023-03-24 9:41 ` Daniel Vetter
2023-03-20 20:07 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87jzz2cejd.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=sedat.dilek@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.