KDE 4 modules structure (again)

[Dominique Devriese]

Maks Orlovich writes:

>> 1 Get rid of all inter-module dependency problems.

> Wrong. It rather creates more of them, as you have to track what
> relies on what individually, rather than at a per-module level. 

> The thing it really can help with is breaking dependency cycles, but
> those don't seem to matter much.

That's what I was talking about.  It's also another one of this kind
of problem that started this thread.

>> 2 Make packagers' lives a *lot* easier by not having to split up
>> the different packages themselves.

> That's only an advantage if you don't consider splitting of packages
> to be a very bad idea, which in my experience as a Mandrake (which
> first had monolythic packages, and then split them) user, it is, due
> to much-much harder maintenance and administration (plus the
> tendency of packagers to split stuff that really has 0 advantage of
> being split).  At any rate, this is not an undisputably good thing
> at all.

1 I am not talking about your life as a sysadmin, but packagers'
  lives.

2 The advantages of split distribution packages is an orthogonal
  discussion, as packages are split by the packagers at the moment.  I
  would argue that their benefits outweigh their disadvantages though.

>> 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.

> 4. Many applications are too small to be in separate modules. KCalc? 
>    KFloppy? come on!

Any particular reason why not ?  Or why we couldn't aggregate very
small apps without any special dependencies in small modules again.
These are things that can be discussed further along in the process.

> 5. Increases the clean build time --- every single module needs to
>    have configure genederate, configure run; doing this per-module
>    is quicker than doing this per-application

This is partly true, but its effects are not so bad because:
1 The amount of work that configure needs to do per-app will
  decrease.
2 The time taken by configure is small compared to the
  time taken for building the source.

> 6. Discourages developers from contributing to multiple
>    applications/diminishes the community aspect of modules.

I don't think this is true.  Developers ignore the current
module-boundaries at the moment as well.  There is no reason to assume
they won't continue to do that after the change.

> 7,8: see above.

I'm not sure what you are talking about here.

cheers
domi