Re: [PATCH 5/5] Add gitmodules(5)

[Josef Weidendorfer <Josef.Weidendorfer@gmx.de>]

On Tuesday 12 June 2007, Junio C Hamano wrote:
> Johannes Sixt <J.Sixt@eudaptics.com> 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).