KDE 4 modules structure (again) (was: structure of kde cvs modules, was Re: libkipi in kdesupport)

[Dominique Devriese]

Cristian Tibirna writes:

> I definitely believe we should break with the current generic
> modules model.  IMO, apps should be hosted independently (each one
> in its module, with their respective docs, web page and
> internationalization. But I'm far from knowing if this is even
> feasible.

I very much second this.  A discussion already occurred on this some
time ago, but it apparently got stuck on David Faure's objections, and
me not knowing konstruct enough.  I'm not satisfied with the outcome
of that discussion, so I'd like to give it another shot.  I am, by the
way, glad to see there is support for this from other people than
the Debian and other distro's packaging people.

Anyway, what is proposed is basically to split modules like kdebase,
kdenetwork, kdemultimedia into app- and lib-sized chunks.  We would
provide a set of build scripts that work with some metadata about the
inter-module-dependencies ( something make-based comes to mind ).

The main advantages would be:

1 Get rid of all inter-module dependency problems.
2 Make packagers' lives a *lot* easier by not having to split up the
  different packages themselves.

Possible disadvantages are:
1 More work for developers, but imho, with a nice set of build
  scripts, this can be mitigated.
2 It would require a big move on the CVS server.  Possibly, this can
  be combined with the move to SVN that should be coming up some time
  soon ?
3 A lot of work is required for doing the move and working on the
  build scripts.  True, but a lot of hands make light work.

About the build scripts: the way I basically see this is to have a
top-level Makefile, containing an entry for every KDE subdir,
containing its dependency information plus some fake targets to do the
./configure's in all the subdirs, plus some fake targets so that you
can for example do "make all".  Configure options can e.g. be passed
via env vars.  Note that this is an attempt at a design, and problems
with it can probably be solved easily.  A problem with this design is
not a valid reason to dismiss the entire proposal.  Anyway, when done
right, this scheme can imho make *everyone's* life wrt. KDE source
easier than it is now.

Can we please have some more discussion about this ?

cheers
domi