[Scummvm-devel] Evolution of Scummvm-tools

[Eugene Sandulenko]

It may appear that putting the tools to the main repo is a good idea. But
that is just at the first glance.

We never demanded a high portabilility for the tools, as we do for the
ScummVM itself. Also the tools have things like wxWidgets, which would be
not really nice to pollute our main codebase with.

Also, your effort on Tony is the one in what, like five years or so? So it
just doesn't justify the effort.

Moreover, you cannot use our common/ code directly, as that one is tied to
backends/, the thing scummvm-tools completely lacks.


Eugene

On 5 January 2016 at 09:16, Arnaud Boutonné <strangerke at scummvm.org> wrote:

> Hi everybody,
>
> First of all, I'd like to present you my best wishes for 2016! And, as
> usual, my more specific wishes of good health and eternal youthfulness :)
>
> I have added those last days a couple of tools in scummvm-tools to
> compress the audio of Tony Tough, and I found scummvm-tools in a very bad
> shape, particularly for MSVC users for whom the compilation was completely
> broken. With the help of criezy and m_kiewitz, it now compiles with
> MSVC2008, but it's still broken for other versions of MSVC.
>
> But that's only a part of the problem. My main issue at this point is that
> the Common code it's currently using is extremely obsolete, which results
> in the use of multiple unsafe functions that are currently forbidden in
> Scummvm/Master by the use of common/forbidden.h. As it's missing a lot of
> other basic stuff, a lot of code is duplicated uselessly like the code in
> Common/utils, the required audio decoders, etc.
>
> I started looking at what would be the consequences of using a common
> Common code, and just fixing the compilation is already quite a large work
> so I'd like to discuss that before starting something which may be rejected
> or severely criticized at the end. And that's even without considering the
> likely regressions we may experience after some code refactoring.
>
> I know there have been historical reasons for splitting apart the
> scummvm-tools, typically because they are user-oriented at the opposite of
> the devtools which are developer-oriented.
> Does it still make sense to keep them in a different repository, rotting
> silently? I have been poked by users trying to compile the tools and unable
> to do so, so I think that at least the user-oriented approach failed for
> that matter...
>
> So my question is: could we consider to put the user tools in Master,
> after making them compatible with the current Common code? and if not, is
> there a git mechanism (criezy mentioned sub-tree) we could use, along with
> some good coding practices?
>
> Thanks in advance for your thoughts
>
> Best regards
> Arnaud
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20160105/2da2a03c/attachment.html>