Having a Tier 0 for cmake and git submodules

[Michael Pyne]

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? 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?).

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 will point out that kdecvs-build (from waaaaay back in the day) had to 
support kde-common/admin, which wasn't much fun either. I was very glad to 
have gotten away from that for KDE 4, especially since each tarball release 
had seemingly 800k added just from KDE 3 buildsystem cruft alone, which had to 
be duplicated into the tarball each time.

> [And FWIW, the strigi setup has always given me a lot of trouble (but
> probably because it was a special case rather than the common case)]

Same here, it was the reason kdesrc-build now supports a "build-script-ignore" 
file to completely hide the strigi/strigi super-repository... but that feature 
ended up being needed for various websites now based in git anyways.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131111/5ed44b8e/attachment.sig>