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

[Einar Johan Trøan Sømåen]

The various sub components are somewhat interdependent, i.e., surface
is used a lot in video/, and almost anything in Common/ is used more
or less everywhere.

Den 12.8.2013 kl. 18:14 skrev Adrian Astley <adastley at gmail.com>:

> What if we were to create individual libraries for different subsets
> of the core? Aka, have one .lib for graphics, one for audio, etc. That
> would allow third parties to choose which parts they want and which
> they don't.
>
> RichieSams
>
>
> On Mon, Aug 12, 2013 at 11:05 AM, A. Milburn
> <fuzzie at users.sourceforge.net> wrote:
>> On Mon, Aug 12, 2013 at 06:52:00PM +0300, Eugene Sandulenko wrote:
>>>> I think such a split off core resulting in an unbranded (i.e. no ScummVM
>>>> name on it except for credits to its origins) project would be a really
>>>> nice thing to do in the long run.
>>>
>>> Now I completely fail to understand why we should not brand it as ScummVM
>>> Library or ScummVM OSystem Library. Removing "ScummVM" brand from the
>>> library title would diminish invaluable volunteer efforts of hundreds of
>>> developers who made it exist in the first place.
>>
>> The branding isn't the name, though. If we leave it branded "ScummVM", then
>> third-party projects would ship their binaries with "ScummVM" branding all
>> over it. I don't think we want that (for support reasons if nothing else).
>>
>> Obviously it would be pointless to remove the ScummVM name from e.g. the
>> credits or the source code or whatever; as Johannes said, we'd want to
>> make sure that the origins of the code was clear and credited in any case.
>>
>>> I agree that it is a good idea to put OSystem and Common code into a
>>> library, but it should stay within main scummvm github repository and be
>>> branded as ScummVM.
>>
>> Well, putting it in a *library* would make no sense, it's only useful as
>> a whole integrated binary.
>>
>> Right now any third-party project is clearly a "second-class citizen":
>> they'd have to keep their own copy of the repository and merge ScummVM
>> into it manually (as ResidualVM does), and manually modify a huge number
>> of files. Having it separated (although not necessarily in a different
>> repository) is the only way I can think of dealing with that.
>>
>> - Alyssa
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Scummvm-devel mailing list
>> Scummvm-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel