Re[2]: [lmi] Linux makefiles update

[Vadim Zeitlin]

On Mon, 17 Mar 2008 17:37:08 +0000 Greg Chicares <address@hidden> wrote:

GC> The actual motivating reason for '.' as a default is written just
GC> above the ctor in 'global_settings.cpp':
GC> 
GC> /// objects of the boost filesystem library's path class are created
GC> /// from these strings, which, if the strings were empty, would trigger
GC> /// exceptions when passed to that library's directory_iterator ctor.
GC> 
GC> '.' is the minimal string that doesn't violate that precondition.
GC> It's just a happy coincidence that '.' works well for msw users.

 FWIW, it doesn't work that well for Unix users. In practice you always
need to specify the "-d $prefix/opt/share/lmi" option when starting lmi_wx.

GC> But the autoconf manual anticipates my philosophical objection:
GC> 
GC> 
http://www.gnu.org/software/libtool/manual/autoconf/Defining-Directories.html
GC> | Note that all the previous solutions hard wire the absolute
GC> | name of these directories in the executables, which is not a
GC> | good property.
GC> 
GC> and I'd like to find another way to achieve the same goal,
GC> especially because there's a practical problem, too.

 I think it's perfectly reasonable to hardcode the default value of the
path in the executable, especially if this "hardcoded" value really comes
from configure and so can be [easily] changed during compilation. I.e. I
don't see how is it worse than hardcoding "." which can't be changed at all.

 Of course, there should be a possibility to change it later but lmi
already provides the "-d" command line option to do it.

GC> Several member variables in one of those classes are documented
GC> as probably belonging in the other. I'm beginning to think that
GC> 'data_directory_' should be in the "configurable" class, which
GC> manages persistent settings in an xml file.

 I thought about doing this but the trouble is that currently you need
data_directory_ to find the configurable_settings.xml file. So I don't see
how is this going to work: if you can find the configurable_settings.xml
file using the default data directory value, you presumably don't need to
change the data directory path. And if you can't find it, you still need to
specify the -d command line option which should override the value from
configuration file (as the usual priority of the configurable options is,
in ascending order, configuration file -> environment variables -> command
line option) anyhow.

 The only other alternative I see is to detect data directory during
run-time from the executable location: at least under Linux we can find the
directory the executable file itself is in (using some non-portable code)
and so we can find the correct path to the data files. I argued against
doing this many times in the past on wx-users mailing list but I guess this
could be an acceptable solution for LMI as it's unlikely to target any
other Unix system than Linux (although playing the devil advocate it's not
really clear why is Solaris under GPLv3 is less free than Linux under
GPLv2).

 But independently of this I still think that we should use pkgdatadir as
the default value, at least under Unix. It's a much more reasonable default
than "." IMO.

 Regards,
VZ