Proposal: branch ECM into ECM6 for KF6

[Ben Cooksley]

On Tue, Jul 6, 2021 at 11:06 AM Friedrich W. H. Kossebau <kossebau at kde.org>
wrote:

> Hi,
>
> during the discussion of the MR for a KDEInstallDirs6 variant I learned
> that
> there is no clear idea yet how ECM should be be released once there are
> both
> KF5 and KF6. And more, it seems so far for ECM there is no version-branch
> planned, but instead would it have to support both Qt5/KF5 and Qt6/KF6 at
> the
> same time for the longer future. With no defined plan when support for
> Qt5/KF6
> should be dropped.
>
> Which also brings a related question: when should all the deprecated ECM
> modules and any other deprecated things there be dropped that have
> accumulated
> in the last years since ECM 1.0? While CMake itself has it's policy
> mechanism
> though so far I think they still keep backward compatibility for anything,
> just doing things different by policy default? And might only dump
> backward-
> compat support really on the next major version?
>
> So when would ECM dump backward-compat support for anything? And, due to
> not
> being co-installable to older version of itself as of now, risk breaking
> builds of older Qt5/KF5 software or forcing the use of dir links
> switching?
> Hello Debian and other LTS systems and trying to develop with more recent
> software at the same time.
>
> IMHO ECM should rather be branched into a major-version-postfixed variant
> as
> well for KF6 times, e.g. "ECM6". And allow a clear cut of legacy things,
> as
> well as some redesign where considered useful. And perhaps even be
> renamed,
> into KFCM, KDE Frameworks CMake Modules (yes, I see the unfortune brand
> name
> conflict while typing, so perhaps something else or no change at all)
>
> Having a version postfix in the name should allow co-installability. Yes,
> there will be some duplication, but Qt5 and Qt6 or Python 2 and Python3
> libraries also duplicate lots of logic ;) and its not that the ECM modules
> are
> MB of installation.
> Maintenance to ensure backward ports of bug fixes between ECM & ECM6 is an
> issue, but might be less trouble than having to support Qt5/KF5 & Qt6/KF6
> at
> the same time (including any cached variables on switching build deps) and
> then the challenge when to annoy some people by dropping legacy support
> they
> rely on.
>
> And those who want to support builds against Qt5/KF5 & Qt6/KF6 from the
> same
> code (which I personally in general recommend against, compromises needed
> just
> hurt), they then would have to do a bit more code branches in cmake code
> as
> well. But they are fine with that in the C++ code, so should they be in
> the
> cmake code (or just copy over any newer CMake modules temporarily if more
> simple).
>
> Also think of test setup - having to test both against Qt5 & Qt6 might be
> more
> troublesome, locally and on CI. More easy if there is just one Qt flavour
> to
> keep in mind.
>

The CI system uses the concept of "platforms" which means a given
combination of Operating System, Compiler and Qt version.
As such, it is impossible (and will remain impossible) to test against two
Qt versions in the same build job.

(Coinstallability doesn't matter here, builds have a terrible habit of
getting mixed/contaminated between the two which just creates trouble -
those who work on Android will be familiar with how a rebuild is required
for ECM changes to be properly picked up)


> My 2 cents as old cmake code writer (who might not be involved in the near
> future)
>
> Cheers
> Friedrich
>

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20210706/a6fc92cb/attachment.htm>