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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel