On Tuesday 12 June 2007, Junio C Hamano wrote: > Johannes Sixt <J.Sixt@xxxxxxxxxxxxx> writes: > > KDE (superproject) > > +- kdelibs (subproject) > > | +- admin (subproject) > > | +- subdir1 > > | +- ... > > +- kdebase (subproject) > > | +- admin (subproject) > > | +- subdir2 > > | +- ... > > +- kdenetwork (subproject) > > | +- admin (subproject) > > | +- subdir3 > > | +- ... > > ... > > If these three instances of 'admin' are truly the same project > created in multiple places in the directory hierarchy, what is > the reason that it is not arranged like this instead? > > KDE > +- admin > +- kdelibs > | +- subdir1 > | +- ... > +- kdebase > | +- subdir2 > | +- ... > +- kdenetwork > | +- subdir3 > | +- ... > ... Actually, on the SVN server you have this structure. KDE applications are put together in groups with other applications of same kind, e.g. kdenetwork contains applications for net access. Now if you want to work on one KDE application e.g. in kdenetwork, you usually checkout _only_ the kdenetwork directory. There is no need to have other parts; e.g. you usually should be able to use the KDE libs from your distribution - no need to checkout kdelibs. However, the "admin" directory above contains the build environment, which has to be checked out so that kdenetwork is able to build. The applications expect the build tools to reside in the admin subdirectory. To checkout admin inside KDE modules such as kdenetwork, SVN externals are used, which is a primitive form of git submodules, to automatically checkout the admin directory on checkout of the KDE module. So the same admin directory only will be duplicated multiple times only on the developers side where multiple KDE modules are checked out. > When kdelibs/subdir1 needs to access stuff in admin, instead of > going to ../admin, it could very well go to ../../admin couldn't > it? Usually, ../../admin will not exist as explicit checkout on a developers machine. It would be possible to require this, but it is much nicer to have each checkout of a KDE module self-contained, including a copy of admin. > It makes me wonder if the KDE's layout you quoted is a good > practice we would want to recommend for other people to follow. > If not, I doubt it is a good idea to model our important concept > after that layout to begin with. In the case of KDE, as far as I remember there is no need to put _everything_ inside of a the mega supermodule. Every KDE module (like kdelibs, kdebase, kdenetwork) has its own configure run and checks dependencies. What IMHO is an important use case for submodules is to have the same submodule in multiple different superprojects, as the admin example shows. Josef PS: Above admin example is from KDE3. KDE4 uses an installed build environment (not really sure). - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
