[Kde-games-devel] Re: Building and packaging concerns for KDE Games

Ian Wadham iandw.au at gmail.com
Thu May 26 04:42:59 CEST 2011


On Wednesday 25 May 2011 10:07:47 pm Stefan Majewsky wrote:
> On Wed, May 25, 2011 at 4:17 AM, Ian Wadham <iandw.au at gmail.com> wrote:
> > I suggest we might have several groupings in KDE Games: libraries,
> > currently maintained games, current games without a maintainer,
> > extragear, discontinued and perhaps playground - maybe data too.
> 
> I don't know how that relates to that, but projects.kde.org defines a
> tree structure of projects (where one repo == one project). The games
> could either become grouped in a single "kdegames" repository (like
> http://projects.kde.org/projects/kdegames/kgoldrunner), or there could
> AFAIK also be additional groups below the kdegames group (like
> http://projects.kde.org/projects/kdegames/maintained/kdiamond).
> 
Thanks, Stefan.  That approach would at least let everyone know what
KDE games exist and can be built/released/distributed.  A division into
maintained/unmaintained might help people decide what to build, etc.

The approach does not help with the actual building and packaging
of "KDE Games" (whatever that may be in future).  With KDE Edu and
other multi-repository projects there is a bit of quick script-writing
going on at the moment.  Well, there is a release to get out ...

One project, KDE Graphics, has some kind of super-repository which
is supposed to contain code to build all the graphics apps, but cannot
clone (check out) all the apps.  Should we have something like that
in KDE Games on git?

> There is also somewhere on projects.kde.org (don't know where exactly)
> an XML file containing all defined projects grouped in the same way.
>
Maybe you are thinking of  http://projects.kde.org/projects/kde-build-metadata
but that project is empty at the moment, apart from the description.

> This is to be used by kdesrc-build or similar scripts for the user to
> be able to say "build kdegames" to compile all the projects inside it.
> One should test this approach with e.g. kdeedu to see how it works;
> reviews are highly appreciated.
> 
kdesrc-build currently uses its own data file (.kdesrc-buildrc, not an XML
file) for which there is a sample in the kdesrc-build package.

I had in mind some kind of directed-graph data-file with nodes being
like packages, apps and libraries and links being like "contains" and
"depends-on".  The idea of "depends-on" is to help analyze and report
on dependencies and prerequisites *before* building, much as my distro
does when you ask to install a package and it depends on other packages
that are also not installed.  I'd like to save time currently spent on failed
builds.

Of course, the script(s) to interprete the hypothetical data-file are also
hypothetical ...  But I did have something like that working in my last paid
job, several years ago.

Cheers, Ian W.


 


More information about the kde-games-devel mailing list