Hi Ian, Am Montag, 28. Mai 2012, 18:22:52 schrieb Ian Monroe: > On Mon, May 28, 2012 at 5:22 PM, Friedrich W. H. Kossebau > > <[email protected]> wrote: > > Hi, > > > > currently it is planned to split the kdesdk into several git repos. > > Just, the split would not simply be done by the existing > > submodules/toplevel dirs. > > > > While it would be simple for all the big programs (umbrello, kompare, > > etc.) > > and plugin types (dolphin-plugins, strigi-analyzer, etc), which would be > > directly mapped to an own repo, the plan is to join in a single repo all > > those small utilities for developers using... > > ... KDE libs/framework: > > * kpartloader - program loading kparts > > > > ... Qt libs/framework: > > * kuiviewer - program displaying UI files > > * kprofilemethod - C++-header for profiling using QTime > > > > ... X libs: > > * kstartperf - program measuring startup time using preload of > > XMapWindow() > > > > ... C++(/C?): > > * kmtrace - program for malloc debugging using glibc's "mtrace" > > > > Has this, splitting into repos, but joining some of them in one submodule, > > been done in one of the other module migrations? From a quick look I could > > not find anything similar so far. > > > > If there was, how was this done? > > What your proposing doesn't actually add any complexity to doing the > SVN->Git. So it's fine.
Good to read :) > > I am asking especially with regard to prepare the buildsystem (good > > Sebastian added this). Is it as simple as just creating a new toplevel > > directory and moving the toplevel dirs of the utils listed above into > > that new directory, so that all the toplevel dirs again map 1:1 to the > > planned git repos? > Yep. This is what we did with KDE Bindings, since it was basically the > move to git which gave an excuse for a directory and build system > reorganization/refactor. Okay, so will do that for those utils as well, move them down one level into a new toplevel dir kdesdk/utils soon (going to be next sunday). > > If so, does anything outside the module depend on the layout/structure of > > the submodules, so that needs to be taken care of as well? Or is > > everything generated automatically from what there is in the module, so > > it also adapts automatically? > > Nothing is automatic. > > > Currently I cannot think of anything. Files should be installed as before > > and all translation catalogs should be named as before (does the actual > > location where they are generated matter?). API dox is also autogenerated > > completely from what files are found. And the submodules moved also do > > not have anything in doc/, so no problem there as well. What is missed in > > this list? > > Well care should be taken with everything on the list. But nothing here that can be done before the reorganization, right? Cheers Friedrich _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
