[lmi] Fixing cross unit tests [Was: master 802eb23 6/6: Refactor for simplicity]

[Greg Chicares]

On 2016-12-06 23:48, Vadim Zeitlin wrote:
> On Tue, 6 Dec 2016 22:25:12 +0000 Greg Chicares <address@hidden> wrote:

[...running a non-native 'cmp', which was a somewhat different subject...]

> GC> The only problem is that it won't work for me in a cross-development
> GC> chroot where system_command() uses CreateProcess() to invoke an
> GC> msw-native 'cmp' that I don't have. I'm sure there's a good solution to
> GC> that, which would also fix all the remaining unit- test problems in the
> GC> chroot:
> GC> 
> GC> Running authenticity_test:
> GC>   Result of 'md5sum --version':
> GC> 
> GC> ** uncaught exception: std::runtime_error: Exit code 12345 from command 
> 'md5sum  --version'.
> GC> 
> GC> Running system_command_test:
> GC> 
> GC> ** uncaught exception: std::runtime_error: Exit code 12345 from command 
> 'grep --quiet abc eraseme'.
> GC> 
> GC> If you could figure out a good solution for that,
> 
>  If I understand the problem correctly, i.e. these errors happen when
> running these programs under Wine, then I think the answer to this is in
> the Wine FAQ:
> 
> https://wiki.winehq.org/FAQ#How_do_I_launch_native_applications_from_a_Windows_application.3F

Inserting something like
  wine cmd /c
or
  wine cmd /c /bin/sh -c
might be useful in some other context, but it's not the best solution
for these unit-test problems. For an msw "host", lmi's system_command()
is a CreateProcess() wrapper. It already works correctly, e.g., when it
is used in `wine ./lmi_wx_shared` to invoke msw-native XSL-FO commands,
so there's no reason to modify system_command() in a wine-specific way.
We don't want any wine-specific modification to the unit test either:
its purpose is to test the system_command() code lmi actually uses.
And that code's purpose is to run msw-native commands, so the problem
is not that it won't run a GNU/Linux command, but rather that we have
not given it an msw-native command to run.

I'm about to commit some changes that fix the problem by using only an
msw 'md5sum.exe' binary (which we already had, for redistribution) in
these unit tests.

> AFAIR, I also could just symlink native programs into a directory in the
> PATH under Wine "drive_c" and this worked too, at least for running them
> from cmd.exe running under Wine -- but I don't see why running them from
> lmi would be any different.

Actually, I did try that, but it didn't work (I didn't try using
'wine cmd /c' because that's not what's wanted for the unit tests):

/opt/lmi[0]$echo $WINEPATH 
Z:\opt\lmi\local\bin;Z:\opt\lmi\local\lib
/opt/lmi[0]$ln -s third_party/bin/md5sum.exe local/bin 
/opt/lmi[0]$readlink local/bin/md5sum.exe
third_party/bin/md5sum.exe
/opt/lmi[0]$wine md5sum.exe --version
wine: cannot find L"C:\\windows\\system32\\md5sum.exe"

Instead, I did this, which does work:

/opt/lmi[0]$rm local/bin/md5sum.exe
/opt/lmi[0]$cp -a third_party/bin/md5sum.exe local/bin 
/opt/lmi[0]$wine md5sum.exe --version           
md5sum (PCP patchlevel 2) (GNU textutils) 1.22