lmi
[Top][All Lists]
Advanced

[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)






reply via email to

[Prev in Thread] Current Thread [Next in Thread]