[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE 4 modules structure (again)
From:       Dominique Devriese <dominique.devriese () student ! kuleuven ! ac ! be>
Date:       2004-03-14 17:26:03
Message-ID: 87k71nmjbo.fsf () student ! kuleuven ! ac ! be
[Download RAW message or body]

Adriaan de Groot writes:

> 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

I wasn't talking about an additional build tool as in a separate
program.  Just some shell or make scripts should suffice..

> Remember to provide pictures

Your pictures were correct :)

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

No xml stuff is necessary imho.  Just a common Makefile in
e.g. kde-common, containing the dependencies in a useful form, is very
much sufficient, I think.

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

Yes, no more app moves would be necessary, no more problems like "we
can't use that lib because it's in another module, and then we'd have
a circular dependency" etc.

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

True.  However, they would also be able to use the new build scripts,
that can make things even easier than before.

cheers
domi
[prev in list] [next in list] [prev in thread] [next in thread]