Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <boris.20230717111132@codesynthesis.com>
In-Reply-To: <boris.20230717111132@codesynthesis.com>
From:   Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue, 18 Jul 2023 09:33:16 +0900
Message-ID: <CAK7LNATAYqG+Y-XubnU9EJqc3R9QhWCn1nfiGMLU63W7k0vpxQ@mail.gmail.com>
Subject: Re: Qt6 port of kconfig qconf
To:     Boris Kolpackov <boris@codesynthesis.com>
Cc:     linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Jul 17, 2023 at 6:27=E2=80=AFPM Boris Kolpackov <boris@codesynthesi=
s.com> wrote:
>
> Is there interest in the Qt6 port of qconf (which is currently Qt5)?
>
> I took an exploratory stab at it and I've managed to make it compile
> and run with relatively few changes, though there are quite a few
> warnings about using deprecated stuff.
>
> I can see three possible approaches here:
>
> 1. Drop Qt5 support and port qconf to be exclusively Qt6. This should
>    allow cleaning up all the deprecated stuff.
>
> 2. Support Qt5 and Qt6 in the same qconf.cc. With this approach it's
>    unlikely we will be able to cleanup the deprecated stuff without
>    turning it into an #if soup.
>
> 3. Leave qconf.cc to be Qt5-only and make the changes in the qconf6.cc
>    copy. This will allow us to clean up all the deprecated stuff but
>    will require applying further changes to two files until we drop
>    support for Qt5.
>
> Thoughts?


I like 1 or 2, depending on the size of #if soup.


--=20
Best Regards
Masahiro Yamada