KDE 4 modules structure (again)
Adriaan de Groot
adridg at cs.kun.nl
Sun Mar 14 16:45:30 GMT 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 14 March 2004 17:19, Dominique Devriese wrote:
> Maks Orlovich writes:
> > 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.
<neil>So the CVS admins and packagers should conspire together against the
actual users of the packages?</neil>
> 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.
Different thread, move along.
> 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.
You can't really _start_ the process untill a lot of later details are worked
out, though. Is KFloppy to be a separately configurable and installable app?
That needs to be decided now, since otherwise you end up with a kdeutils that
is .. the same as kdeutils now.
> > 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.
Finding maximum length of command-line args ... 524128
that takes a hell of a long time. The app-specific stuff in each configure
seems to be pretty limited - basically, the content of the configure.in.in in
the apps srcdir in the current setup. However, all the boilerplate needs to
be done, as well as checking for a gob of extra libs all of a sudden (need to
check for x-lib and y-lib and kdebase and kdelibs and kdelibs-woodchuck and
kdelibs-2.6.14-ac3-pw1).
- --
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)
iD8DBQFAVIwqdqzuAf6io/4RAsCGAJ9ikOVLAeGiX4PLXMkfwkJ3T6fyYACfYMKl
arlUaKAQWqpnnU4i5YWB/iU=
=6H/H
-----END PGP SIGNATURE-----
More information about the kde-core-devel
mailing list