Having a Tier 0 for cmake and git submodules

[Ben Cooksley]

On Mon, Nov 11, 2013 at 10:48 PM, David Faure <faure at kde.org> wrote:

> On Monday 11 November 2013 01:06:33 Michael Pyne wrote:
> > On Sun, November 10, 2013 20:11:07 David Faure wrote:
> > > On Sunday 10 November 2013 13:44:09 Michael Pyne wrote:
> > > > I would highly recommend doing something similar to what was done for
> > > > strigi  when it was split into 5 git modules.
> > >
> > > I think you misunderstood the issue?
> > >
> > > A super-repo might help automating "building all of KF5", but it
> doesn't
> > > solve the issue of "defining the install dirs and compiler settings in
> the
> > > separate karchive tarball".
> > >
> > > The stuff in the super-repo won't be in the karchive tarball, so it's
> > > unrelated to the discussion in this thread, unless I'm missing
> something.
> >
> > I believe the idea is that the karchive tarball would have an implicit
> > dependency on a "KF5 umbrella" supermodule, no?
>
> No, not at all.
>
> The KF5 umbrella thing is just a generic cmake file that allows to write
> find_package(KF5 COMPONENTS KArchive KIO etc.)
> instead of 10 different find_package calls.
> KArchive doesn't need this at all.
> (Higher-tier frameworks might need it, but AFAICS they can also do without
> it).
>
> The thing that we're considering a git submodule for, is these 3 files:
> KDECMakeSettings.cmake  KDECompilerSettings.cmake  KDEInstallDirs.cmake
>

Isn't a separate Git repository for three files just a touch overkill? It
is quite a lot of overhead.
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.
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?

Chances are we are going to require new ECM releases anyway due to other
components in ECM like Find modules.


>
> > I.e. what we're calling ECM
> > now would be replaced by a "tier0"... although, re-reading Kévin's
> email, it
> > seems that ECM would still be a separate dependency (but made generic)
> and
> > that tier0 would be implicitly included with all tier1 repositories (or,
> > *all* repositories?).
>
> The above 3 files would be included in all repositories.
>
> But again, my preferred option would be to rename them ECM and be done
> with it
> -- all this stuff is useful outside the KDE community. I'd certainly want
> to
> use that in any Qt app I would write professionally too:
> * the actually working RPATH handling
> * all the very sensible defaults like "include current dir", "enable
> automoc",
> "don't relink deps of shared libs"....
> * the stricter compilation flags to get more warnings
>   [after we fix the too-magic changing of the meaning of Debug]
>
> OK, forcing -DQT_NO_CAST_FROM_ASCII on to apps is a bit over the top, I
> think
> we should actually revise that and only set it in the frameworks
> themselves.
>
> And finally KDEInstallDirs.cmake can stay in ECM as is. One doesn't have to
> use it if one doesn't want kde install dirs.
>

I'm in favour of this as well, otherwise it will just become another
complication which will:
a) Make it even harder for the CI system to support building multiple
versions of KDE.
b) Increase the barrier to entry for those using plain Qt code to use Tier
0 KDE Frameworks.


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