[Scummvm-devel] Fedora ScummVM package (Was: Merging TsAGE engine into trunk)

John Willis John.Willis at Distant-earth.com
Sat Apr 9 10:11:38 CEST 2011

Max, Torbjörn,

> > As an afterthought: Maybe we should modify our configure script to
> > reject
>  > --enable-all-engines when --enable-release is used?
> Sounds reasonable to me. Should it throw an error, or just silently drop
the --
> enable-all-engines flag? Also, should --enable-release prevent enabling
> unstable engines, or is it just blanket statement --enable-all-engines
that we
> want to block? (I guess you could argue that if you enable engines
> individually, then you probably know what you are doing, and that there
> be cases when you want to try and compile even unstable engines with
> optimization.)

Please do the part of the former and not the latter :).

Telling the user that --enable-release and --enable-all-engines are mutually
exclusive and giving a clear warning that explains why is fine but disabling
release builds of a specific engine with --enable-release and the engine
name is a very bad idea as (particularly on the low end/embedded stuff)
release builds of WIP engines are a common debugging and testing tool. As in
'I wonder if it runs out of RAM in a release build?' ;-).

I wonder if we should allow some override for all engines in release mode in
fact as a lot of the low end ports set --enable-release by default and this
would fail potentially legitimate dev builds with all engines on buildbot.
Maybe --enable-unstable-engines with a warning? I don't really know but I am
anxious that we don't cause devs pain because of sloppy packaging. Warnings
and clear messages (plus breaking the existing workflow) seems the sensible



More information about the Scummvm-devel mailing list