[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] wxmsw-2.9.0 (svn trunk) anomaly
From: |
Vaclav Slavik |
Subject: |
Re: [lmi] wxmsw-2.9.0 (svn trunk) anomaly |
Date: |
Thu, 26 Feb 2009 01:37:45 +0100 |
Hi,
On Mon, 2009-02-23 at 19:32 +0000, Greg Chicares wrote:
> - thus: './lmi_wx_shared --figure_it_out --data_path=/opt/lmi/data'
> I get:
>
> 18:34:25 PM: Can not enumerate files 'opt\lmi\data\skin.xrc' \
> (error 3: the system cannot find the path specified.)
> 18:34:25 PM: Cannot load resources from '/opt/lmi/data/skin.xrc'.
Note that because LMI is built as native MSW app, "truly" absolute path
to --data_path would be c:/opt/lmi/data or, better yet, c:\opt\lmi\data
(although /opt/lmi/data = \opt\lmi\data is a valid MSW path, absolute on
the current disk).
The bug comes from ambiguity in wxXmlResource::Load(): it accepts both
filenames and wxFileSystem URLs. wxFileSystem code gets confused by MSW
filenames of /this/form on the trunk -- apparently, some tweaks were
made to it to deal with leading "/". Reverting that would break other,
probably more common, cases, so I'd rather not do it.
Let me offer three independent fixes instead, each of the sufficient to
fix this regression:
(1) I fixed wxXmlResource::Load()'s heuristic to correctly deal with
this situation in r59149
(http://svn.wxwidgets.org/viewvc/wx?view=rev&revision=59149). This fix
doesn't require any changes to LMI code. In other words, the bug is gone
with latest wx trunk.
(2) I also added wxXmlResource::LoadFile(wxFileName) that doesn't suffer
from this ambiguity in r59150
(http://svn.wxwidgets.org/viewvc/wx?view=rev&revision=59150). In LMI
code, calls to xml_resources.Load() could -- and in my opinion should --
be replaced with xml_resources.LoadFile() to avoid the ambiguity.
(3) Finally, the bug wouldn't manifest itself if
global_settings::data_directory() returned absolute path. This is only a
workaround that hides the real wx defect, of course. However, I think it
still makes sense to do it, because it makes data_directory() resistant
to CWD changes and that is IMHO a good thing (even though LMI currently
doesn't change CWD as far as I can tell). A patch for this is below [*].
Regards,
Vaclav
[*] The patch to make data_directory() absolute:
Index: global_settings.cpp
===================================================================
RCS file: /sources/lmi/lmi/global_settings.cpp,v
retrieving revision 1.19
diff -u -r1.19 global_settings.cpp
--- global_settings.cpp 27 Dec 2008 02:56:42 -0000 1.19
+++ global_settings.cpp 26 Feb 2009 00:33:07 -0000
@@ -32,6 +32,8 @@
#include "handle_exceptions.hpp"
#include "path_utility.hpp"
+#include <boost/filesystem/operations.hpp>
+
/// Initialize directory paths to ".", not an empty string. Reason:
/// objects of the boost filesystem library's path class are created
/// from these strings, which, if the strings were empty, would trigger
@@ -52,9 +54,10 @@
,pyx_ ("")
,custom_io_0_ (false)
,regression_testing_ (false)
- ,data_directory_ (".")
,regression_test_directory_ (".")
-{}
+{
+ set_data_directory(".");
+}
global_settings::~global_settings()
{}
@@ -107,7 +110,7 @@
void global_settings::set_data_directory(std::string const& s)
{
validate_directory(s, "Data directory");
- data_directory_ = s;
+ data_directory_ = fs::system_complete(fs::path(s));
}
void global_settings::set_regression_test_directory(std::string const& s)