Re: Heads-up: kdeutils is moving to git
Jeremy Whiting <jpwhiting <at> kde.org>
2011-08-19 12:25:29 GMT
I'm looking to migrate kdeaccessibility this weekend also. It's mostly ready, just polishing it a bit in svn first (making each application build on its own or part of kdeaccessibility). I'll backport these changes to the 4.7 branch when it's in git.
I'm wondering the same thing, kdeaccessibility has a Mainpage.dox (as did kdeedu before it split) that we are wondering where to keep also, besides the top CMakeLists.txt for the released tarball. I agree a git repo for each module makes sense rather than putting this stuff into superbuild (which I discussed with Allen the other night). So it would be something like this:
kdeaccessibility.git (holds CMakeLists.txt, and Mainpage.dox)
-- jovie.git
--kaccessible.git
--kmag.git
--kmousetool.git
--kmouth.git
with similar setups for kdeedu, kdegraphics, etc.
On the other hand if Dirk is going to use superbuild to do the release tarballs we could just "dump" this non-superbuild stuff into there Mainpage.dox, any top level README, etc. since we need to have module specific CMakeLists.txt in there anyway for superbuild to work.
thoughts?
Jeremy
On Fri, Aug 19, 2011 at 5:37 AM, Yury G. Kudryashov
<urkud.urkud <at> gmail.com> wrote:
Thomas Zander wrote:
> What do others think about a solution of that kind?
> And is it applicable to our other (former) modules too?
There is a "superbuild" script; you can find details in kde-buildsystem ML.
--
Yury G. Kudryashov,
mailto: urkud <at> mccme.ru
<div>
<p>I'm looking to migrate kdeaccessibility this weekend also. It's mostly ready, just polishing it a bit in svn first (making each application build on its own or part of kdeaccessibility). I'll backport these changes to the 4.7 branch when it's in git.<br><br>I'm wondering the same thing, kdeaccessibility has a Mainpage.dox (as did kdeedu before it split) that we are wondering where to keep also, besides the top CMakeLists.txt for the released tarball. I agree a git repo for each module makes sense rather than putting this stuff into superbuild (which I discussed with Allen the other night). So it would be something like this:<br><br>kdeaccessibility.git (holds CMakeLists.txt, and Mainpage.dox)<br>-- jovie.git<br>--kaccessible.git<br>--kmag.git<br>--kmousetool.git<br>--kmouth.git<br><br>with similar setups for kdeedu, kdegraphics, etc.<br><br>On the other hand if Dirk is going to use superbuild to do the release tarballs we could just "dump" this non-superbuild stuff into there Mainpage.dox, any top level README, etc. since we need to have module specific CMakeLists.txt in there anyway for superbuild to work.<br><br>thoughts?<br>Jeremy<br><br></p>
<div class="gmail_quote">On Fri, Aug 19, 2011 at 5:37 AM, Yury G. Kudryashov <span dir="ltr"><<a href="mailto:urkud.urkud <at> gmail.com">urkud.urkud <at> gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote">
<div class="im">Thomas Zander wrote:<br><br>
> What do others think about a solution of that kind?<br>
> And is it applicable to our other (former) modules too?<br>
</div>There is a "superbuild" script; you can find details in kde-buildsystem ML.<br>--<br>
Yury G. Kudryashov,<br>
mailto: <a href="mailto:urkud <at> mccme.ru">urkud <at> mccme.ru</a><br><div>
<div></div>
<div class="h5">
<br>
_______________________________________________<br>
release-team mailing list<br><a href="mailto:release-team <at> kde.org">release-team <at> kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/release-team" target="_blank">https://mail.kde.org/mailman/listinfo/release-team</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>