Follow-up Comment #12, bug #21576 (project freeciv):

I think the default.lua is the opposite (or maybe both-ways): Before ruleset
specific script.lua was split out of it, every ruleset had the default.lua. So
I think Christian now has multiplayer/default.lua from an ancient version even
when playing modern version.
However, we cannot simply always use default/default.lua, but a ruleset must
have an option to define one itself. While we try to keep default/default.lua
as generic as possible, it doesn't work for all kind of rulesets. So there
might be default.lua in a ruleset that currently hasn't (it's somewhat likely
in case of alien ruleset if we don't make default/default.lua to much more
dynamic in its behavior)
I'm not sure how include in .lua would work.

As for what we support, I think user is responsible to uninstall before making
new install. The problem is having one version installed (presumably stable
release) and developing/running development version from build dir. Then the
development version sees files of the installed version in FREECIV_xxx_PATH.
So I think stubs should be present when ever recent release has files that may
cause problems for running from the build dir. It's then the definition of
"recent" that we're missing, but as a Debian user I count at least package in
current stable (but not oldstable) Debian and anything newer as "recent".
And yes, I now realize that the original bug does not count as 2.4.2 blocker
by these definitions. It's only when 2.5.0-beta1 gets released when S2_4
*development version to be run from build dir* must have stubs in place.


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to