Benoit Timbert <[EMAIL PROTECTED]>:
> There is two kind of possible collision between two UMC addons :
> - Macros :
> If two addons use the same macros with a different definition they can
> collide (except if #undef is used wisely) so one of the two addons will be
> broken
> - WML data :
> If two addons define units with the same ids, races with the same ids,
> movement types with the same id,... Then one of the two addons will use the
> definitions from the other addon, which might be wrong.
OK, I think I understand.
This kind of issue is why wmlscope has an idea of namespaces built into it.
You may recall that soon after I first wrote wmlscope I reorganized
the Wesnoth data tree so essentially all the core content lives under
data/core and each campaign lives under a single identifiable directory
beneath data/campaigns (which is why I invented _main.cfg). Here is
why I did that...
When you invoke wmlscope, what you are supposed to hand it (after the
control options) is a series of directory arguments. Each directory is
treated *as the root of a namespace*. Multiple definitions of the
same macro or resource name within a single namespace (a single named
file tree) trigger a warning message from wmlscope, But the same
macro or resource may be defined in *different* namespaces without
causing an error message. Except...
The first directory argument is special. It is assumed to be the
"core" namespace. It exports definitions rather than just importing
them. Redefinitions of a core macro or resource in any other
namespace are treated as errors.
And now you know why I had to reorganize the data tree. It was so I
could write this:
wmlscope data/core data/multiplayer data/themes data/campaigns/*
and have it be shell-expanded into the right list of namespace roots, without
either (a) having to specify the list of campaibns, or (b) include markup
specifying namespace scopes in the WML.
I think what you are telling me is that addons all need to be treated like the
core namespace -- that is, they export definitions rather than just importing
them, and any clash with another exported definition is an error.
Matters are slightly complicated by the fact that wmlscope doues not
presently check for {unit,race,movetype} ID collisions; wmllint does some
of that, but not enough for what you want. That's a detail that can be
fixed with an hour or two of Python programming.
In principle, what we could do is run a slighly enhanced wmllint every time
an add-on is submitted to the campaign server and reject the add-on with
an explanatory message if it detects a potential collision.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
