I don't really see the point of this option, though. It seems the only use case is to override a previous --enable-all-engines option, in which case you just shouldn't have passed that option in the first place.
I don't really see the points of those options either.
On its own --disable-all-unstable-engines doesn't do anything, and using --enable-all-engines --disable-all-unstable-engines is the same as using no option at all. So I agree with wjp that in such a case we should not use --enable-all-engines in the first place. And similarly on its own --enable-all-unstable-engines is the same as --enable-all-engines. So the only setting I can see that is now easy and would have been difficult before is to disable all stable engines and enable the unstable ones (--disable-all-engines --enable-all-unstable-engines), but that doesn't seem like a terribly useful setting to me.
I definitely want to enable only the unstable engines sometimes, for example to build a separate scummVM with only unstable engines that could be distributed in addition to a scummVM with only the stable engines (if it runs out of memory)
Also it is good for testing to be able to only build with unstable engines. My main reason was to be able in the buildbot to selectively disable only the unstable engines, after the option --enable-all-engines.
But in general, I think it should be possible to select any combination of {stable, unstable} using combinations of the enable-all options
I definitely want to enable only the unstable engines sometimes
This is a no go. The purpose of having unstable engines is that they are not for the public use. On the buildbot we are enabling them solely for the compilation tests. Some of those do not even provide useable results, e.g. Chewy. Thus, when enabling those, you need to enable them one by one.
Since your port compiles well on the buildbot with all engines on, just doesn't run, I suggest to continue it doing so. You might consider not enabling all engines in the nightly builds, so those could be useable.
This comment has been minimized.
I would appreciate it if you discussed changes like this beforehand.
This comment has been minimized.
Sorry will do next time. I thought it was a minor thing since it is completely optional.
This comment has been minimized.
I don't really see the point of this option, though. It seems the only use case is to override a previous --enable-all-engines option, in which case you just shouldn't have passed that option in the first place.
This comment has been minimized.
I don't really see the points of those options either.
On its own
--disable-all-unstable-enginesdoesn't do anything, and using--enable-all-engines --disable-all-unstable-enginesis the same as using no option at all. So I agree with wjp that in such a case we should not use--enable-all-enginesin the first place. And similarly on its own--enable-all-unstable-enginesis the same as--enable-all-engines. So the only setting I can see that is now easy and would have been difficult before is to disable all stable engines and enable the unstable ones (--disable-all-engines --enable-all-unstable-engines), but that doesn't seem like a terribly useful setting to me.This comment has been minimized.
I definitely want to enable only the unstable engines sometimes, for example to build a separate scummVM with only unstable engines that could be distributed in addition to a scummVM with only the stable engines (if it runs out of memory)
This comment has been minimized.
Also it is good for testing to be able to only build with unstable engines. My main reason was to be able in the buildbot to selectively disable only the unstable engines, after the option --enable-all-engines.
But in general, I think it should be possible to select any combination of {stable, unstable} using combinations of the enable-all options
This comment has been minimized.
This is a no go. The purpose of having unstable engines is that they are not for the public use. On the buildbot we are enabling them solely for the compilation tests. Some of those do not even provide useable results, e.g. Chewy. Thus, when enabling those, you need to enable them one by one.
Since your port compiles well on the buildbot with all engines on, just doesn't run, I suggest to continue it doing so. You might consider not enabling all engines in the nightly builds, so those could be useable.
And yes, this commit should be reverted.