On Sat, Mar 15, 2008 at 04:00:07PM +0100, Benoit Timbert wrote:
> This is a very good idea.
> It used to use the following macro to do this :
> #define INCLUDE PATH
> [EMAIL PROTECTED]/Package_Name/{PATH}}
> #enddef
> (that macro was undefined at the end of Package_Name.cfg)
>
This is used to include other WML data. With the changes it would
like:
#define INCLUDE PATH
{/~/PATH}
#enddef
if "data/campaigns/Package_Name/" is the current add-on packages local
package base path otherwise if it is a differents local package base
path it would look like:
#define INCLUDE_EXT PATH
{/data/campaigns/Package_Name/{PATH}}
#enddef
> Btw how does it work in there rare case you have two files that have the same
> path, one relative to the main data directory and one relative to the user
> data
> directory ?
In this case it would return the one in the user data dir because we
set user data to be the front of the search path list.
> Other than that, i think it would be nice to change a little bit our syntax so
> we can distinguish more easily file inclusion from macro inclusion.
> Currenlty when you do
> {SOMETHING}
> you don't know if you include a file called SOMETHING or if you call a macro
> with the same name.
> Perhaps we should use a leading / instead of just {path} (ie {/path}) to mean
> it's a ressource relative to the global wesnoth base so this problem would no
> longer exist ?
>
I did another check and I see that this is only for file inclusions
but the general resource path specification should be similiar
It seems that your proposed changes seem appropriate, but I would
always use '/' infront of 'path' inside of { } to differentiate
between preprocessor symbols and paths.
This would lead to:
- path for a resource relative to the global wesnoth base path
- ~/path for a resource relative to the local package base path
- {/path} for inclusion of a resource relative to the global
wesnoth base path
- {/~/path} for inclusion of a resource relative to the local package
base path
> How about case-sensitiveness ?
> Currently you can design scenarios that work under case-insensitive OS like
> Windows, but are broken under case-sensitive OS. It would be nive to have a
> common behaviour here.
> Does PhysFs deal with this ? (i gave a quick look, but probably too quick)
>
No PhysFs does not deal with it and neither should wesnoth.
The only thing that could be done is force all lowercase file entries
in add-ons and force all path specifications to be lowercase.
But I don't think there is need for this because it is a scenario bug.
> I think WML should not be able to write any file...
> You're talking about savefile and addons fetch, right ?
>
Well I don't know. If there are WML related commands or tags that let you
write something and an add-on uses these to write a path it should not be
allowed to write outside of its local package base path.
If add-ons are depending on other add-ons they know the name of these
and hence their local package base path.
Jon Daniel
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
