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

List:       kde-games-devel
Subject:    Re: [Kde-games-devel] Move to git now?
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2012-02-02 23:53:45
Message-ID: 7863945B-9C4A-4DE6-BC48-50B365DC9822 () gmail ! com
[Download RAW message or body]

On 02/02/2012, at 11:28 PM, Stefan Majewsky wrote:
> On Thu, Feb 2, 2012 at 12:53 PM, Frederik Schwarzer <schwarzer@kde.org> w=
rote:
>> As for the list of all games ->
>> http://projects.kde.org/kde_projects.xml
>> Every "project" under the "kdegames" module would be a game.
>> No, I do not consider that info easily digestible. Someone would have
>> to write a script to extract the needed data. Preferably generic
>> enough to be useful to all modules. But well, the irony. ;)
> =

> 1. kdesrc-build reads this information. Don't know about the rest, so RTF=
M. ;-)

If we have one repo per game, kdesrc-build will rely on us keeping that
XML file up-to-date at all times =85

> 2. Alexander Neundorf of CMake fame is working on a "SuperBuild". This
> is still WIP, but I think that it is very likely to become the
> preferred workflow for compiling a split kdelibs.

Alex already wrote superbuild CMakefile scripts for a few KDE modules.
We could emulate one of them for KDE Games.  That is what I was
referring to.  It also would have to be kept up-to-date somehow.

A bit off topic, but I think the way KDE should go is to have a relational
database to record everything known about components, dependencies,
contents of modules, etc., etc.  Once you have that it is not too hard keep=
 track
of everything and generate scripts and other outputs for particular purpose=
s.

We were doing that in the 90s, in my last paid job, to manage builds and
releases of millions of lines of code, using just RCS as the base source-co=
de
control system, would you believe.  Application programmers only had to use
forms-type screens to manage their checkouts and checkins.  Only a couple
of people (I was one) had to do the admin work.

However, I was unable to persuade Alex and others on the build list re the
RDB idea.  FWIW, Macports (on Apple Mac) uses a DB to drive everything. e.g.

Tara:~>port info kdegames4
kdegames4 @4.7.4 (kde, kde4)
Variants:             debug, docs
Description:          A variety of games made with the KDE4 development pla=
tform
Homepage:             http://www.kde.org
Build Dependencies:   cmake, pkgconfig, automoc
Library Dependencies: qt4-mac, phonon, kdelibs4, kde4-runtime, libsndfile,
                      qhull, ggz-client-libs
Platforms:            darwin
License:              GPL-2+ LGPL-2+ GFDL-1.2
Maintainers:          snc@macports.org, sharky@macports.org

Tara:~>port installed | grep snd
 libsndfile @1.0.25_0 (active)

And when you do "port install xxxxx @nnnn" it automatically finds all the d=
ependencies
of "xxxxx" version nnnn, notes which ones you already have, diagnoses any v=
ersion
clashes, then fetches whatever you need and compiles and builds it in the c=
orrect order.

Cheers, Ian W.

_______________________________________________
kde-games-devel mailing list
kde-games-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel
[prev in list] [next in list] [prev in thread] [next in thread]