On Wed, Jan 12, 2011 at 08:28, Marcel Wiesweg <marcel.wies...@gmx.de> wrote: > >> Then why split at all? All your points above suggest that having a split >> repository has no benefit for you and its unclear wether it'll ever have >> any benefit. > > I left out the points why splitting is a benefit and collected only > those small problems arising with splitting ;-) > >> Having said that, if someone in your team wants to setup a repository that >> has a shell script to pull the other ones in, there's no technical reason >> speaking against that (AFAIK). > > Summing up yours and Ian's answer, we could setup a super repo for convenience > of building the whole module, with some technical solution to pull in the > split repos, but require the modules to build standalone.
Well through the cunning use of 'export', I think you could make it all build at once, and standalone. Thats just an unproven theory though. :) > Brings two more questions: > > a) should CMake modules be moved up to kdelibs or down to the submodule that > needs them? This is really a very good question. A CMake module that is used by more then one part of repo of kdegraphics fits the definition for being included into kdelibs. So rather then make two+ copies of a cmake file, adding it to kdelibs makes sense. We had to grapple with this issue for kdebindings. We solved it differently though, basically installing cmakes used in common from the libraries used in common. If you have such a library you could do it that way. But kdebindings mostly didn't have "install with kdelibs" as an option, since most of it doesn't depend on KDE. > b) Would the super-repo be associated with the KDE/kdegraphics project on > projects.kde.org, or what place and name would it have? Yes to the former, I think it could just be a repository associated with the KDE/kdegraphics. Ian _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
