Separating everything ?

Martin Sandsmark martin.sandsmark at kde.org
Sat Feb 9 13:21:53 UTC 2013


On Fri, Feb 08, 2013 at 05:39:29PM +0100, Alexander Neundorf wrote:
> IMO this is very much not a black-and-white situation.
> It is not "leave everything in one huge blob as it is now" vs. "put every
> tiny library in its separate repository", there are steps in between.

Well, if you need to use git submodules anyways to automatically check out
all modules, why does the number of repositories matter?


> I for one would prefer if we stay with a moderate number of repositories.
> khtml e.g. is big, this should be separate (will it actually still exist
> ?). I would guess the "solutions" each deserve a separate repository.

What do you consider big? KHTML is "only" 13MB, and Solid is 2.2MB, is that
also big?

(And KHTML has more activity than many other modules, so I assume it will
continue to exist.)


> Just a bunch of libraries can happily live together in one repository, and 
> optionally also be built in one step.
> Have a look e.g. at the current state of kdelibs/tier1/.
> Those can (since a few days) be built and installed completely separately.
> Next to them I added a directory superbuild/, mainly for my own
> convenience, to build them all in one go.
> If you simply run cmake there, nothing is built, you have to explicitely 
> enable the libs you want to build, and there are not dependencies between 
> them, so this is simple and straightforward.
> Those together are still small, fast to download, and easy to package 
> separately.

Is there any reason this superbuild directory could not be in a "top-level"
repository, with the other modules as git sub-modules?


> I don't see an advantage in splitting such things into separate
> repositories.

Well, it would be more consistent, instead of having some modules as separate
directories and some bundled together.

It also makes the repositories you need to check out to fix something
smaller. Just checking out a 5MB repository can be a royal PITA in some situations,
fast and stable internet access isn't available everywhere.

-- 
Martin Sandsmark



More information about the Kde-frameworks-devel mailing list