<div dir="ltr">On Mon, Nov 11, 2013 at 10:48 PM, David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Monday 11 November 2013 01:06:33 Michael Pyne wrote:<br>
> On Sun, November 10, 2013 20:11:07 David Faure wrote:<br>
> > On Sunday 10 November 2013 13:44:09 Michael Pyne wrote:<br>
> > > I would highly recommend doing something similar to what was done for<br>
> > > strigi  when it was split into 5 git modules.<br>
> ><br>
> > I think you misunderstood the issue?<br>
> ><br>
> > A super-repo might help automating "building all of KF5", but it doesn't<br>
> > solve the issue of "defining the install dirs and compiler settings in the<br>
> > separate karchive tarball".<br>
> ><br>
> > The stuff in the super-repo won't be in the karchive tarball, so it's<br>
> > unrelated to the discussion in this thread, unless I'm missing something.<br>
><br>
> I believe the idea is that the karchive tarball would have an implicit<br>
> dependency on a "KF5 umbrella" supermodule, no?<br>
<br>
</div>No, not at all.<br>
<br>
The KF5 umbrella thing is just a generic cmake file that allows to write<br>
find_package(KF5 COMPONENTS KArchive KIO etc.)<br>
instead of 10 different find_package calls.<br>
KArchive doesn't need this at all.<br>
(Higher-tier frameworks might need it, but AFAICS they can also do without<br>
it).<br>
<br>
The thing that we're considering a git submodule for, is these 3 files:<br>
KDECMakeSettings.cmake  KDECompilerSettings.cmake  KDEInstallDirs.cmake<br></blockquote><div><br></div><div style>Isn't a separate Git repository for three files just a touch overkill? It is quite a lot of overhead.</div>
<div style>What harm are these three files doing to ECM? If a non-KDE project doesn't want to use them - it doesn't have to include them.</div><div style>Is it really going to be a big problem for ECM to make a new release if KDE needs any changes to these three files? </div>
<div style><br></div><div style>Chances are we are going to require new ECM releases anyway due to other components in ECM like Find modules.</div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> I.e. what we're calling ECM<br>
> now would be replaced by a "tier0"... although, re-reading Kévin's email, it<br>
> seems that ECM would still be a separate dependency (but made generic) and<br>
> that tier0 would be implicitly included with all tier1 repositories (or,<br>
> *all* repositories?).<br>
<br>
</div>The above 3 files would be included in all repositories.<br>
<br>
But again, my preferred option would be to rename them ECM and be done with it<br>
-- all this stuff is useful outside the KDE community. I'd certainly want to<br>
use that in any Qt app I would write professionally too:<br>
* the actually working RPATH handling<br>
* all the very sensible defaults like "include current dir", "enable automoc",<br>
"don't relink deps of shared libs"....<br>
* the stricter compilation flags to get more warnings<br>
  [after we fix the too-magic changing of the meaning of Debug]<br>
<br>
OK, forcing -DQT_NO_CAST_FROM_ASCII on to apps is a bit over the top, I think<br>
we should actually revise that and only set it in the frameworks themselves.<br>
<br>
And finally KDEInstallDirs.cmake can stay in ECM as is. One doesn't have to<br>
use it if one doesn't want kde install dirs.<br></blockquote><div><br></div><div style>I'm in favour of this as well, otherwise it will just become another complication which will:</div><div style>a) Make it even harder for the CI system to support building multiple versions of KDE.</div>
<div style>b) Increase the barrier to entry for those using plain Qt code to use Tier 0 KDE Frameworks.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> I have to admit I'd like that even less, if we're going to be making<br>
> "one-stop git modules" for developer convenience I'd argue that we should<br>
> replace ECM in that list of dependencies with Alex's proposed "KF5<br>
> umbrella", which gives the same number of overall dependencies but still<br>
> has the submodule magic (to hide the actual number of dependencies) and<br>
> retains the generic/KDE split for CMake settings. As you mention elsewhere<br>
> we'd still need to support a separate release of our KDE CMake build system<br>
> files for third-party software to depend on.<br>
<br>
</div>I think you still misunderstand what the "KF5 umbrella" is, please take a look<br>
at kdelibs-frameworks/tier1/kf5umbrella.<br>
<br>
If I try to factor out that name from your paragraph, I think what you're<br>
suggesting is a git supermodule that bundles ECM and KDE-ECM (the 3 KDE* files<br>
plus possibly KF5Config.cmake) into a single git module?<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE, in particular KDE Frameworks 5<br><br></div></div></blockquote><div><br></div><div style>Regards,</div><div style>Ben</div></div></div></div>