From: James T. <ja...@fl...> - 2022-08-24 08:26:16
|
> On 24 Aug 2022, at 09:17, Florent Rougon <f.r...@fr...> wrote: > > I understand that it is “legal” for a provider to ignore the context > arg, however when this is the case, users who rely on this particular > provider wouldn't provide a misleading context that causes an unintended > path to be tried first, right? Unintended like > $FG_ROOT/Materials/regions/Materials/base/landclass-mapping.xml. When adding the context feature, my guess is the extra paths which are tried would be ‘obviously wrong enough’ that this would not be significant. > > When you read how 'include' attributes are processed in a PropertyList > file: > > // simgear/simgear/props/props_io.cxx:271 > else if( att_name == "include" ) > { > try > { > SGPath path = simgear::ResourceManager::instance() > ->findPath(val, SGPath(_base).dir()); > > realizing that SGPath(_base).dir() is the directory (let's call it d) > where the XML file that contains the 'include=...' directive is located, > do you think that the author's intent was that the value of this > 'include' attribute could be interpreted as relative to something else > than directory d? The issue that XML / PropertyList include syntax predates both the context argument and the resource system in general :) It’s just a ‘defined / expected behaviour’ (as Erik was saying) that any relative path *anywhere* will be tried relative to FG_ROOT, and the other providers. To me this is the same as -I arguments to a compiler: when you write a path in a #include<> declaration, you’re expecting it to be tried relative to all the include paths passed on the command line, *and* also relative to the including file. Kind regards, James |