[Kde-scm-interest] Module layout proposal: Split kdegames-data from kdegames

[Stefan Majewsky]

[CC kde-scm-interest for notification only]
[CC kde-buildsystem for feedback on the proposed build system changes]
[CC kde-packagers for feedback on the implied changes to package layouts]
[@CC: please keep discussion on k-c-d and k-g-d only]

Moin moin,

==== EXECUTIVE SUMMARY ====

I propose to move the data files from the kdegames module into a new
kdegames-data module to
1. facilitate the move of the remaining source code to Git (while a
method of storing binary data files in Git efficiently is still being
worked on) and
2. enable developers to fetch and compile the kdegames source without
having to download the data files again.

==== DETAILED PROPOSAL ====

kdegames is among the few modules that have not yet switched to Git.
The main concern is that the kdegames source tree contains tons [1] of
binary data files, which Git is known not to handle well. All
discussions about moving to Git (on scm-interest and games-devel) have
just let to bikeshedding about how to handle the binary files with
git. I propose to postpone this specific problem and move on with the
Git transition *now*, especially since the solution I want to propose
has added benefit.

I propose to split a new module kdegames-data from kdegames, meaning that:

1. kdegames-data should be built and installed before kdegames.
2. Any kdegames application will refuse to start when the
corresponding data files have not been installed.

Number 2 is a protective measure because, currently, about all games
won't run correctly or look utterly broken without proper indication
of the problem.

If this proposal is implemented, the kdegames module, that is: the
source code, can move to Git without worrying about the data files.
These can move at any later point in time, when a wise solution has
been worked out by our Git specialists. I'll repeat to get this clear:
I'm not proposing to let the data stay in SVN forever. What I want is
to disentangle the fates of the source code and the data files, for
the benefit of both.

The added benefit of this solution is that distributions will be
encouraged to package data files separately. Because this data (and
esp. its format) changes very seldomly only, developers will not need
to checkout this giant mass of data from our SCM servers, but can
instead use the packages provided by their distribution. The same
holds true for drive-by contributors: They only have to clone a tiny
repo containing the source code of the game which they want to hack
on, without fetching megabytes of data files which they already had
installed.

If this proposal is accepted not later than by the end of next week, I
will be able to implement the following changes before the soft
feature freeze (Thu, October 27):

1. Create the new module in SVN, move data files from the current
kdegames module. The toplevel directory is still divided by
applications, of course.
2. Setup the buildsystem for kdegames-data using
macro_optional_add_subdirectory() as in kdegames, so that data can be
selected for installation on a per-application basis. Each set of
application data will additionally install an empty marker file which
indicates that data is available for this application (something like
${DATA_INSTALL_DIR}/${APP}/hasdata; please suggest better schemes if
there are).

My roadmap also includes the following changes to be implemented
before the hard feature freeze (Thu, November 10):

3. Adjust the buildsystem of kdegames to exclude applications from
compilation when required data files are missing. The exclusion can be
overridden by a documented CMake switch. This is consistent with how
other runtime dependencies of kdegames are handled (see
kdegames/kajongg/CMakeLists.txt).
4. Make all applications abort with a visible warning when data files
are missing.

In both cases, "data files are missing" is detected by checking for
the existence of the marker files installed by kdegames-data (see
point 2). If a developer for some reason wants to use the application
without the data files, he can do so by touching the marker file
manually.

As has been said before, if there are no objections, I would like to
implement this proposal starting from the end of next week (Sat,
October 22), to make sure that the required changes get into 4.8.

Greetings
Stefan

[1]
$ find -type f -regextype posix-egrep -regex
'.*\.(wav|ogg|svg|svgz|jpg|png)' | xargs du -hsc | grep total
86M total
$ du -hsc (*~(.svn|.git)) | grep total
113M total
The latter uses zsh extended glob: (*~(.svn|.git)) matches everything
except .svn or .git