[Kde-games-devel] Re: A Thought About The Version Control System

[Parker Coates]

On Wed, Apr 13, 2011 at 14:08, Wolfgang Rohdewald wrote:
> On Mittwoch 13 April 2011, Frederik Schwarzer wrote:
>> From what I remember it seemed that there was a slight
>> preference on split repos
>
> there is one aspect not mentioned yet
>
> right now the CMakeLists.txt of a single game expects
> to be called from kdegames/CMakeLists.txt - it is not
> apparent how to cmake build a game separately. If
> every game has its own repo, I expect this to change.

Of course, although my impression is that this should be relatively
straightforward to do if/when the time comes.

> the kde on windows port is trying this - make installers
> for single KDE applications. There are two GSoC projects
> about this
>
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/costashsrc/1
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/tudalex/1
>
> and stand-alone executable CMakeLists.txt would certainly
> help there
>
> of course this is also orthogonal to splitting into repo
> per game but it matches the repo per game scenario better, IMHO.

It's not actually completely orthogonal, as a split to per-app repos
would convert a lot of internal dependencies on libkdegames to
external dependencies. For example if we're building the entire
module, Killbots shouldn't check for the presence of libkdegames, as
the library is going to be built and installed together with it. On
the other hand, if we're building only Killbots if must explicitly
check that libkdegames is installed, otherwise linking will fail. The
handling of CamelCase includes would probably also need to be
modified.

Of course, for someone with more CMake-foo than myself, there's
probably a relatively clean way to implement such conditional checks.
I just wanted to point out that converting isn't just as simple as
writing standalone application CMakeLists.txt files and converting
kdegames/CMakeLists.txt to a bunch of add_subdirectory() calls.

Parker