[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251205182334.GB3974306@ax162>
Date: Fri, 5 Dec 2025 11:23:34 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Graham Roff <grahamr@....qualcomm.com>, Nicolas Schier <nsc@...nel.org>,
Jonathan Corbet <corbet@....net>, linux-kbuild@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
Nicolas Pitre <nico@...xnic.net>
Subject: Re: [PATCH v2] Support conditional deps using "depends on X if Y"
On Fri, Dec 05, 2025 at 09:01:51AM +0100, Arnd Bergmann wrote:
> Agreed, the question is whether a small improvement in
> readability is worth the complexity of having multiple
> ways of expressing the same thing.
I think the biggest thing that this patch has going for this is that
there is minimal additional complexity within scripts/kconfig and that
it basically internally converts the 'depends on ... if ...' into the
simple 'depends on' so there is no behavioral difference. The diff stat
of the core of the change speaks to that I think.
scripts/kconfig/lkc.h | 2 +-
scripts/kconfig/menu.c | 12 +++++++++++-
scripts/kconfig/parser.y | 6 +++---
3 files changed, 15 insertions(+), 5 deletions(-)
> I don't see anything that the new syntax would allow
> that we were currently missing.
I see this as syntactic sugar. It is just giving users a different (and
possibly more intuitive) way of expressing the same thing but I
understand being concerned about people misusing it (even though I think
it is already hard enough to get dependencies right sometimes).
> This is the bit that frequently confuses developers with the
> current syntax, and I agree it would be nice to have a better
> way, but I'm not sure the proposal actually helps enough to
> warrant a mass-conversion of existing Kconfig files.
I do agree that the 'depends on A || !A' syntax is confusing and that
this does not really address that but I think that is besides the point
here. I also agree that it is probably not worth converting existing
users to this syntax (unless there is solid reasoning), I would not want
to see cleanup patches of that nature, just use in new code.
> With the existing syntax, this could be expressed as
>
> depends on FOO = BAR
>
> or
>
> depends on (FOO && BAR) || (!FOO && !BAR)
>
> and I don't see how the new syntax is an improvement
> over these.
Maybe the "if" syntax could be easier to understand with actual real
world values? I cannot think of anything off the top of my head but
real world dependencies might read a bit more naturally with this
syntax.
> Overall, I'm not convinced by this patch. I have no strong
> objection to anything in here, but I'm worried that extending
> the syntax adds more problems than this one solves.
Thanks a lot for the input!
Cheers,
Nathan
Powered by blists - more mailing lists