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

[Matthew Hoops]

On Tue, Aug 13, 2013 at 3:56 AM, A. Milburn
<fuzzie at users.sourceforge.net> wrote:
>
> 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.
So, if none of these are viable, this pretty much corroborates me
saying it's "not doable".

> > 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.
Right.

> 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.
Again, this comes back to "not doable". It would be a pain for us to
keep in sync and would be a pain for any other project to keep in
sync.

> > 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.
The modular stuff was more of "oh, hey, I don't need PICTDecoder so
I'll just disable it" or something -- changes that would benefit
smaller ports like the NDS as well as anyone else who would use the
code.

-Matt