Re: [lmi] Calculation summary: tidying up loose ends

[Evgeniy Tarassov]

On 11/7/06, Greg Chicares <address@hidden> wrote:
> On 2006-11-7 16:19 UTC, Evgeniy Tarassov wrote:
> > On 11/7/06, Wendy Boutin <address@hidden> wrote:
>
> >> * Configuring 'install' for new *.xml, *.xsd, and *.xsl
> >>
> >> Greg and I use this command to run 'lmi':
> >>   c:/opt/lmi/bin[3]$./lmi_wx_shared.exe --ash_nazg --data_path=../data
>
> Indeed we do; yet I have long thought that the relative path
>   --data_path=../data
> is a poor practice and that your suggestion
> > - configurable_settings.xml in Greg's directory (c:/opt/lmi/data):
> or something like that would be better. I guess it ought to be in
> 'configurable_settings.xml'. However, it's not; it's governed by
> 'global_settings.?pp' and mediated by 'data_directory.?pp'. This is
> a throwback to the bad old days when msw application data customarily
> went in the msw 'system' directory; today, it looks in $(pwd) instead,
> but we've never taken the time to rework it thoughtfully, and this
> isn't the best time to do that.

Oh, sorry, my motivation for separating configurable_settings.xml was
something different. After looking at the code from
configuable_settings.cpp:
|    std::string filename = "/etc/opt/lmi/" + configuration_filename();
|    if(access(filename.c_str(), R_OK))
|        {
|        filename = AddDataDir(configuration_filename());
|        if(access(filename.c_str(), R_OK))

I have concluded that if one specifies
 --data_path=../dir
to lmi_wx.exe at startup then executable will search for
configurable_settings.xml in that data directory.

But now i can see that for some reason configurable_settings
constructor is executed before the program has a chance to parse its
command line parameters and the only place where program looks for
configurable_settings.xml is the current directry and the
'/etc/opt/lmi/'. So my starting assumption was wrong.

> > Now i do realize that if the xslt_directory is not specified or empty
> > then it is treated as a relative path, but the problem is that this
> > path is relative to the executable (current directory) and not to the
> > configurable_settings.xml.
>
> IIRC, it's actually the current $(pwd), which can change while the
> program is running, under msw at least; but one of the C++ files
> mentioned above is supposed to save the original directory at
> startup.

I have fixed it so that any xml/xslt resource needed by program is
search like the following:
- filename = file name like 'html.xsl' or 'format.xml'
- xslt_directory = configurable_settings::xslt_directory()
- data_dir = global_settings::data_directory()

[very simplified pseudo-code]
std::string get_actual_xml_filename(filename)
{
   if(filename.is_absolute())
       return filename;

   filename = xslt_directory / filename;
   if(filename.is_absolute())
       return filename;

   filename = data_dir / filename;
   return filename;
}

I think this schema is the most flexible one allowing at any point to
specify an absolute path not breaking anything.

It allowes also to have the same usual data files in directory and xml
related files in another one.

> > To workaround it you could specify an absolute path in your
> > configurable_settings.xml. Like so:
> > - configurable_settings.xml in Greg's directory (c:/opt/lmi/data):
> > <configurable_settings>
> >  <xslt_directory>c:/opt/lmi/data</xslt_directory>
> > </configurable_settings>
>
> Wendy, does that work for you, and would it work for end users?
> Or do they have data files in the same directory as the program?

Now even if we use relative paths in
configurable_settings::xslt_directory it will account the data
directory provided at startup too. It will of course work if the files
are in the sane directory as the executable.

> Some output gets written wherever $(pwd) points, and users have
> asked for all output to be placed in one location. That's a good
> idea for us to implement later.

Oh, now i understand that there is a bug in configurable_settings
code. As i have mentioned above if one specifies --data_path, then it
does not affect configurable_settings.xml and it is read from the
current directory. but when the code writes the
configurable_settings.xml, the parameters are already passed and a new
file will be created in that that directory, and as a consequence it
won't be picked up during the next launch.

Do you want me to fix this by saving the configurable_settings.xml
real path and using it afterwards?