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

List:       kde-core-devel
Subject:    Re: Redefining kdelibs and kdebase
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2005-08-29 18:26:17
Message-ID: 200508292026.18282.nicolasg () snafu ! de
[Download RAW message or body]

On Sunday 28 August 2005 10:56, David Faure wrote:
> On Saturday 27 August 2005 21:44, Nicolas Goutte wrote:
> > > How it would look in svn:
> > > kdelibs/kde3support/
> > > kdelibs/kdecomponents/
> > > kdelibs/kdeframework/
> > >
> > > kdeworkspace/
> > >
> > > kdebase/
> > >
> > >
> > > Even though componants, compat and framework are seperate packages
> > > they could be in kdelibs.  So end the end we would only be making one
> > > new module.
> >
> > If there is an effort of making a split then please show it as separate
> > modules too, otherwise it is nearly useless to make this discussion.
>
> I am the one who suggested subdirs in kdelibs instead of three new modules.
> The reason is that this way we keep the good old habit of: building KDE is
> as simple as "build+install kdelibs, then compile any other KDE code you
> want". Everyone is used to that, and if we change to "build+install three
> modules", anyone who is not reading this discussion will be completely lost
> as to how to build KDE. The idea is that release this code as three
> tarballs though,
> kdelibs-components (*)
> kdelibs-framework
> kdelibs-kde3support
> (and kdelibs-workspace IMHO, for workspace libs; libs for kicker applets,
> screensavers etc.)
>
> So what's in SVN as kdelibs/components, kdelibs/framework,
> kdelibs/kde3support and kdelibs/workspace would be packaged as the above 4
> tarballs (same for binary packages). Keeping kdelibs in the name makes it
> easy for everyone to
> understand that this is where the KDE libraries come from.
>
> I would even suggest kdebase/workspace and kdebase/apps too, for the same
> reasons. Smooth migration...

Then why not doing like the extragear and playground modules and have:

kdelibs/components
kdelibs/framework
kdelibs/kde3support

Each would be independant, have an admin module, would correspond to a 
tarball, would correspond to a single generic translation file (replacements 
of kdelibs.po).

And you could check them out with
svn checkout kdelibs
in one go, nevertherless...

Have a nice day!


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