[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871qg8cirv.fsf@protonmail.com>
Date: Sat, 12 Aug 2023 16:44:40 +0000
From: Rahul Rameshbabu <sergeantsagara@...tonmail.com>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scripts: merge_config: Add flag to prevent unsetting config option
On Tue, 08 Aug, 2023 04:04:37 +0900 "Masahiro Yamada" <masahiroy@...nel.org> wrote:
> On Mon, Aug 7, 2023 at 1:13 PM Rahul Rameshbabu
> <sergeantsagara@...tonmail.com> wrote:
>>
>>
>> On Sun, 06 Aug, 2023 23:19:55 +0900 "Masahiro Yamada" <masahiroy@...nel.org> wrote:
>> > On Sun, Jul 30, 2023 at 6:42 AM Rahul Rameshbabu
>> > <sergeantsagara@...tonmail.com> wrote:
>> >>
>> >> Overriding a previously defined entry for a config option with 'is not set'
>> >> may be undesirable in some fragment configuration setups.
>> >
>> > Then, you should remove the 'is not set' entry from the fragment.
>>
>> I had a feeling that was the expectation. Just for reference, my flow
>> for generating fragments looks like the following.
>>
>> 1. make allnoconfig
>> 2. make menuconfig # select the options that I desire for the fragment
>
>
> Sorry, I could not understand
> how these steps generate a fragment file.
>
> You will get a full .config file
> after 'make menuconfig'.
Yep, this is right. I am not really generating a fragment this way but
rather full configs with minimal options that I end up wanting to merge
together. What's your process for generating fragments you need? Just
dumping the options you want in fragment files and letting make properly
select the dependencies?
>
>
>
>
>
>> We can drop this patch if this is the expected developer flow. I
>> realized that overriding with 'is not set' entries in a fragment is
>> likely desirable, so I made this behavior change as part of a flag that
>> can be set by the user.
>>
>> --
>> Thanks,
>>
>> Rahul Rameshbabu
>>
--
Thanks,
Rahul Rameshbabu
Powered by blists - more mailing lists