I can't really work on this bug (no time and I am on linux) but here is some
other infos.
IIRC the planned design on _main.cfg is, when its presence is detected, to
skip other files and directories. These files are then loaded by includes in
the _main.cfg. So, not detecting the special status of a _main.cfg will
cause multiple readings of cfg.
From the mac editor filesystem logs of Ivanovic, I think it's maybe what's
going on here. He doesn't seems to properly detect the special status of
data/_main.cfg, so it start to explore the tree and load a lot of things (+
the data/_main.cfg). The second special code for searching
sub-directory/_main.cfg add complexity to the result. A possible experiment
to test/hack this hypothesis is to change the "data/" in game.cpp or
editor_main.cpp and instead use "data/_main.cfg".
An other possible cause of this bug, is the ugly "path//file.cfg" which we
can see in the logs. I don't know if there is OS difference (or in file
functions implementations) to handle these "//", but it's a risk. Btw, about
this, an other experiment for mac/win users: use "path" instead of "path/"
in code and cfg.
Finally, IMHO this bug reveals a flaw in the design of this _main.cfg :
exploring files and directories differently if we have or not a _main.cfg.
This seems like a non-standard files behavior for me and not very KISS. I
think that I understand the idea of _main.cfg in campaigns/something to have
a "package" but why generalizes this idea on all our filesystem? The second
idea to have this file parsed before can be done with WML tricks: some ifdef
MAIN_CFG_ALREADY_DEFINED, or hide cfg in subdirectory and then call them
with subdir/file.cfg.
Sadly, I haven't a strong idea to replace this design. Maybe use the classic
method to add argument to choose how to explore directory like {path/ -r}
and code whatever parameter/behavior we need ? Or use more often the
previous hack and do direct include of the _main.cfg instead of just the
directory name ({data/core/_main.cfg} instead of {data/core/})?
I have no opinion about using boost, but I still think/hope that this bug
it's just a little error in the code only visible on some OS.
Alink
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
