Having a Tier 0 for cmake and git submodules
Alexander Neundorf
neundorf at kde.org
Sun Nov 10 18:42:46 UTC 2013
On Sunday 10 November 2013, David Faure wrote:
> On Sunday 10 November 2013 17:57:00 Kevin Ottens wrote:
> > Now back to the submodules sha-1 update... The only thing I see to easily
> > overcome that for our developers, is to have a hook, which would update
> > the submodules for all the frameworks every time someone pushes in the
> > tier 0 repository. Is it something the sysadmins would agree to have on
> > the server?
> >
> > Any opinions or thoughts on that?
>
> I'm very much reminded of kde-common/admin which was an external in all kde
> modules in kde3 times. Which is both good and bad :-)
>
> Good = same way to avoid a dependency just for the buildsystem, bad = makes
> a few actions as a developer more complex, like as you mentionned, having
> to update sha1s manually, in the case of git.
>
> Actually, I just realized that the same solution (to the same problem) is
> used in KDSoap (https://github.com/KDAB/KDSoap.git) with its autogen
> subdir which is a git submodule (to share it with other similar libs).
> It's actually working OK, the only downside is indeed the need to update
> it manually when committing a fix to a buildsystem file.
>
> Where git submodules is better than svn externals is that this won't slow
> down updating one's checkout (a separate command is needed for updating
> the submodule locally). But forgetting to do so isn't a risk, since "git
> status" (and the commented out list in git commit, etc.) reminds you to do
> so.
>
> If we're really just talking about the 3 cmake files for KDE, updates won't
> actually happen very often.
>
> OK, let's go for it.
>
> Let us NOT call it tier0 though :-)
>
> Note that we still need to ship them as a standalone package too, for
> people who might want to use them - KDE apps outside of git, or Qt apps
> that want to benefit from the rpath stuff that's currently only in there
> [although that's a bug IMHO], etc.
just to make sure I understand correctly:
this would mean that the 3 KDE* files from ecm plus the KF5 umbrella
Config.cmake file would be used within KF5 as a git submodule.
Users of KF5 can get access to it via using the installed KF5 umbrella
package, or not if they don't want to.
Is this the plan ?
If so, can we then release ECM soon, with some cleanups ?
This would also mean no more quick fixes/temporary hacks in ECM.
And we should definitely get Stephens opinion on that.
Alex
More information about the Kde-frameworks-devel
mailing list