Re: [lmi] --gui_test_path and implicitly created output files

[Greg Chicares]

On 2014-12-14 14:31, Vadim Zeitlin wrote:
> 
>  It turns out that implementing --gui_test_path is not completely trivial
> as some files are unconditionally created by lmi in the current directory:
> this is the case for at least the files created by mec_server which is used
> from mec_view with just base_filename() as the file name (i.e. "unnamed")
> and ".monthly_trace" debugging files created when illustrations debugging
> is enabled. In both cases we can't currently force creation of these files
> in the directory specified by the --gui_test_path command line option.

Okay, I see that call to base_filename():

void mec_view::Run()
...
    server(base_filename(), input_data());

But it looks like '.ill' files do something very similar:

void IllustrationView::Run(Input* overriding_input)
...
    illustrator z(mce_emit_nothing);
    z(base_filename(), input_data());

So...do you have in mind a method that would take care of '.ill'
but not '.mec'? [This question is probably academic in light of the
discussion that follows.]

>  I see the following possible solutions:
> 
> 0. Ignore the problem for these files and just ensure that they are deleted
>    after the end of the test (currently this doesn't happen neither, as
>    they are created as a side effect and not explicitly, so I didn't even
>    know originally that they were created by lmi).

Sounds good to me.

> 1. Solve the problem by changing the current directory before executing the
>    code creating these files and restoring it after doing it. I didn't test
>    this yet, but I think it should work. I also however dislike this
>    solution because it's fragile and could result in subtle (i.e. the worst
>    sort) differences between the code behaviour when it's being tested and
>    when it's being used normally.

I agree--let's reject that.

> 2. Change lmi itself to allow customizing the directory used for these
>    files creation. I don't know if you would agree to doing this, but I'm
>    afraid this is unavoidable if we want to really solve this problem, i.e.
>    if (0) is not good enough.

Maybe I'm missing something, so let me try expressing this in my own words.

Input files are created by the user, who can exercise full control over the
directory in which they're saved. When 'wx_test' creates such a file, we'd
rather have it saved in 'gui_test_path'. When 'wx_test' loads a file that
we've provided, we'd rather provide it in 'gui_test_path' and have 'wx_test'
look for it only in that directory.

Output files may be created in various places. There's a configurable setting
  <print_directory>/var/opt/lmi/spool</print_directory>
which lmi uses for PDF files it creates, along with '.xml' and 'fo.xml' files
that are a side effect of PDF creation. That's a deliberate lmi behavior that
at least one user regarded as important, and 'wx_test' should follow it.

Some lmi output files are created...in the directory where the program happens
to be run, I suppose: the 'monthly_trace' and '.mec.tsv' files, for instance.
These and quite a few others are created as deliberate side effects. Let's
first address the theoretical question where they should be created: I guess
the FHS would prefer /var/opt/lmi/ . Is it worth changing lmi to do that?
At this moment, I'll say "no"; no user has complained about the present
behavior, and if I've read the FHS correctly, lmi can do absolutely whatever
it pleases in /opt/lmi because /opt/ is not very restrictive. Now...if we
decide not to worry about this for lmi itself, then we certainly shouldn't
worry about it for 'wx_test'; and if I've specified something to the contrary,
then I suppose I was mistaken.

I'm thinking that if 'wx_test' is presented with a choice--e.g., it's doing
"File | Save as"--then it should choose 'gui_test_path'; but otherwise we
shouldn't worry about this at all. We'll delete all output files if we can;
if 'wx_test' crashes and leaves some files lying around, that's acceptable.