[Scummvm-devel] Bringing our Core Code to another Level?

A. Milburn fuzzie at users.sourceforge.net
Tue Aug 13 09:56:25 CEST 2013


On Mon, Aug 12, 2013 at 07:06:03PM -0400, Matthew Hoops wrote:
> But, really, the second method makes things impossible for us to keep
> in sync. Right now, if there's a change to the core code, every single
> calling piece of code has to be updated; it forces us to keep our
> engines in sync with the core code. How would they be kept in sync,
> anyway? Would we just rely on "most recent revision" of the code?

So having two separate completely independent trees would clearly drive
everyone mad I think! Some obvious options to make it work:

* Don't split the repos at all: As I said earlier in the thread, we *could*
  just logically split the core (make it easier to rebrand, add this
  pluggable engines code, etc). That's how this whole conversation started
  I guess.

* Have a separate core repo, and then merge from it into ScummVM repo. This
  is 'nicer' technically since it's trivial to also merge from that into
  other repos. Also it means we can make ScummVM-specific hacks only in the
  ScummVM repo copy. But it's bad in the sense that you then have two copies
  in the core and it'll be a pain to make changes in the core and merge them
  and people will just commit to ScummVM's copy and etc..

* Something like git submodules which would be tied to a specific hash for
  every ScummVM revision. Alas, this would probably be way too complicated.

> In the end, I don't see what benefit *at all* this has for ScummVM.

As I said, forking the core seems like an obvious option for projects if we
think we shouldn't be bothering about third-party projects at all. It just
seems a real pity to end up with a bunch of fragmented projects from a
technical point of view (even if it's clear that we mostly want them separate
from a project point of view).

Some at least logically-split core would avoid ending up with another (or
yet more) forks of the ScummVM core code because our existing core is full
of ScummVM-only bits and there's no way to replace the branding/engines/etc
without manual merge fun every time.

Note that I think trying to truly *share* a core will most likely just lead
to arguments about whether we do/don't want certain code, still rejecting
anything which isn't used by some in-ScummVM-tree engine, and a heap of other
problems which I'll avoid enumerating here.

So I'm not sure I really envisage any projects using a split-out core
directly as opposed to forking it. Just, as it is, if some project seriously
forks the core then it will diverge quickly. That's not ideal and certainly
it meant so far I avoided doing it for example.

I think we'd also gain from a more logically-split development procedure in
some ways, especially if we could move to development branches for some
core code and then have separate stabilisation periods for backends. But
that is again a separate story (since we could simply start branching in
our existing repo).

> It seems to me that it would be much more logical to work on making
> our common code more modular while keeping it in-tree. That way we can

Well, myself I don't care at all about it being modular. There's not much
point trying to cut (source) code out of the core unless you're a project
like ResidualVM who are forced to do it, imo.

But if you mean things like the pluggable engines and rebranding and bla then
I hope in any case that we can agree (as a project) that it's a good idea if
only because it would make merging code back/forth between projects a lot
less painful.

But in any case I think it's a good idea to discuss this.

- Alyssa




More information about the Scummvm-devel mailing list