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

[Adriaan de Groot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Administrativish: in this thread, as in any other, if there is a significant 
change in the subject, please start a _new_ thread, with a _new_ subject, 
perhaps referring to it in a message in the old thread for continuity. This 
applies to the SVN sub-discussion here already. If there's a kde-cvs-admin 
list, that's where that discussion belongs.]

On Sunday 14 March 2004 13:55, Dominique Devriese wrote:
> 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.

Two things to keep in mind:

1) Requiring any build tools other than auto* and make is a perilous step, 
bound to cause a lot of discussion and noise. That's why unsermake, which 
arguably works better than make+auto*, isn't mandatory. Konstruct is not the 
answer either. There have been several threads about using other build 
systems, most died due to the basic requirement that you need to be able to 
build all of KDE reliably on all the platforms we have for it to be 
acceptable at all, and that's a lot of work. Me, I've been guilty of 
implementing 85% of a build system using the AAP build tool.

2) The debian and other packaging people's suggestions are usually based on an 
idea of what "the customer" wants, and are about rearranging KDE so that some 
default packaging scheme will serve their needs best. Since this is CVS for 
developers, I think developer's convenience (a) should come first, and then 
packagers (b), and then users-who-want-to-install-kde-from-source (c) last. 
Of course, having something that really is convenient for (a) will probably 
help (c) as well.

> Anyway, what is proposed is basically to split modules like kdebase,
> kdenetwork, kdemultimedia into app- and lib-sized chunks.  We would

Remember to provide pictures with any rearrangement-suggestion, to show the 
dependency effects. Right now we have (beware, ascii-art, use view->fixed 
font in kmail):


                   kdelibs
                  / | | | \
            every other module

and for you, you'd get:

                   kdelibs
                  /   |   \
              X-lib  Y-lib Z-lib
                |     |      \
              X-app  Y-app   Z-app

at least, that's how I understand your 

       

> provide a set of build scripts that work with some metadata about the
> inter-module-dependencies ( something make-based comes to mind ).

Heh, I tossed around an xml dtd for this kind of information over a year ago 
(not on this list) and decided that it'd just be one more thing that started 
and didm't gather the momentum needed to survive.

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

As for (1), I can see an advantage that Y-app can now depend on Y-lib _and_ 
X-lib, which would make some kinds of reuse possible (and would have made it 
possible to keep kmail in kdenetwork, since it could depend on pim-libs 
then). 

As for (2), that assumes that packagers want to package the way you're setting 
up the CVS structure. The POLA in BSD-land says that you will not be thanked.


(Saving rest of reply for other messages in this thread)
- -- 
pub  1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <groot at kde.org>
                     Would you like a freem?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAVIpFdqzuAf6io/4RAvUmAKChrp64GJoG7NEwBSO67c163ZJ/ygCfebr4
iw3BD2qGzqKPRa1VMSkfkSs=
=/c5i
-----END PGP SIGNATURE-----