<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 6, 2021 at 11:06 AM Friedrich W. H. Kossebau <<a href="mailto:kossebau@kde.org">kossebau@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
during the discussion of the MR for a KDEInstallDirs6 variant I learned that <br>
there is no clear idea yet how ECM should be be released once there are both <br>
KF5 and KF6. And more, it seems so far for ECM there is no version-branch <br>
planned, but instead would it have to support both Qt5/KF5 and Qt6/KF6 at the <br>
same time for the longer future. With no defined plan when support for Qt5/KF6 <br>
should be dropped. <br>
<br>
Which also brings a related question: when should all the deprecated ECM <br>
modules and any other deprecated things there be dropped that have accumulated <br>
in the last years since ECM 1.0? While CMake itself has it's policy mechanism <br>
though so far I think they still keep backward compatibility for anything, <br>
just doing things different by policy default? And might only dump backward-<br>
compat support really on the next major version?<br>
<br>
So when would ECM dump backward-compat support for anything? And, due to not <br>
being co-installable to older version of itself as of now, risk breaking <br>
builds of older Qt5/KF5 software or forcing the use of dir links switching? <br>
Hello Debian and other LTS systems and trying to develop with more recent <br>
software at the same time.<br>
<br>
IMHO ECM should rather be branched into a major-version-postfixed variant as <br>
well for KF6 times, e.g. "ECM6". And allow a clear cut of legacy things, as <br>
well as some redesign where considered useful. And perhaps even be renamed, <br>
into KFCM, KDE Frameworks CMake Modules (yes, I see the unfortune brand name <br>
conflict while typing, so perhaps something else or no change at all)<br>
<br>
Having a version postfix in the name should allow co-installability. Yes, <br>
there will be some duplication, but Qt5 and Qt6 or Python 2 and Python3 <br>
libraries also duplicate lots of logic ;) and its not that the ECM modules are <br>
MB of installation.<br>
Maintenance to ensure backward ports of bug fixes between ECM & ECM6 is an <br>
issue, but might be less trouble than having to support Qt5/KF5 & Qt6/KF6 at <br>
the same time (including any cached variables on switching build deps) and <br>
then the challenge when to annoy some people by dropping legacy support they <br>
rely on.<br>
<br>
And those who want to support builds against Qt5/KF5 & Qt6/KF6 from the same <br>
code (which I personally in general recommend against, compromises needed just <br>
hurt), they then would have to do a bit more code branches in cmake code as <br>
well. But they are fine with that in the C++ code, so should they be in the <br>
cmake code (or just copy over any newer CMake modules temporarily if more <br>
simple).<br>
<br>
Also think of test setup - having to test both against Qt5 & Qt6 might be more <br>
troublesome, locally and on CI. More easy if there is just one Qt flavour to <br>
keep in mind.<br></blockquote><div><br></div><div>The CI system uses the concept of "platforms" which means a given combination of Operating System, Compiler and Qt version.</div><div>As such, it is impossible (and will remain impossible) to test against two Qt versions in the same build job.</div><div><br></div><div>(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)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
My 2 cents as old cmake code writer (who might not be involved in the near <br>
future)<br>
<br>
Cheers<br>
Friedrich<br></blockquote><div><br></div><div>Cheers,</div><div>Ben<br></div></div></div>