Re: [lmi] Problems with the Cygwin tests

[Greg Chicares]

On 2019-05-07 15:05, Vadim Zeitlin wrote:
> On Tue, 7 May 2019 12:00:49 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I'll let you know when I've finished all of that, and I

I've finished all of that.

> GC> hope that at that time you'll be able to retest everything in
> GC> 'INSTALL', along with
> GC>   ./nychthemeral_test
> GC>   ./gui_test
> GC> in cygwin so we'll know cygwin is fully supported.

Except that you might like first to look through the dozen or so commits
that I just pushed, because I could have missed something important, or
in the last commit I may have followed shellcheck's recommendations too
zealously. But everything builds and tests out perfectly here.

>  Here are the testing results:
> 
>  For the gui_test:
>  
> 1. LMI_COMPILER=gcc LMI_TRIPLET=i686-w64-mingw32 need to be explicitly set
>    in the environment. I don't know if this is expected, i.e. I thought the
>    script would autodetect their values, but I could well have been wrong.

For now, it's a good idea to set both:
  export LMI_COMPILER=gcc
  export LMI_TRIPLET=i686-w64-mingw32
For the long term...I'm struggling with this issue. It's the only major
difference between trunk and foo/multiarch (or it should be, once I merge
trunk into foo/multiarch again). I'm not sure which one is better:

 - foo/multiarch consolidates all of {$PATH, $WINEPATH, $PERFORM, etc.}
   into one script, and calls that script wherever it seems sensible.
   To switch architectures, you need to do something like:
     $export LMI_COMPILER=gcc ; export LMI_TRIPLET=x86_64-w64-mingw32 ; . 
./set_arch.sh
   but the reward for that inconvenience is that the script is "perfect"
   AFAICT, so all of the settings it controls are always consistent.

 - trunk uses no such script. Required settings are stored in makefiles
   and scripts, exactly where they're required (except of course for the
   imperfection you point out). There's a certain righteousness in setting
   $WINEPATH only in 'msw_generic.make', because it's unnecessary for
   cygwin. And if the makefiles and scripts are perfected, then perhaps
   we don't ever need to think specify anything like LMI_TRIPLET on the
   command line: we'd specify it iff we are deliberately switching to a
   different architecture, and simply executing
     LMI_TRIPLET=x86_64-w64-mingw32
   should make it all just work. Or that's the dream.

If one of those two alternatives seems obviously right to you, please
let me know, because I'm still torn between them. I'm starting to think
that 'set_arch.sh' is preferable.

> 2. There are extra quotes around "$PERFORM" on the line invoking wx_test.

Fixed, there and in the other script whose name is harder to spell,
in Latin script at least.

>  With these caveats, the GUI test passes:
> 
>       time=51305ms (for all tests)
>       SUCCESS: 21 tests successfully completed.
>       NOTE: 4 tests were skipped

Excellent. I don't suppose we can make this faster except by making lmi
itself faster.

>  For the nychthemeral test:
> 
> 3. We still need to set LMI_{COMPILER,TRIPLET} manually.

Discussed above. I think I exported both in
  gwc/.zshrc
and regarded the problem as solve, at least for anyone who copies that to '~'.

> 4. We also need to export PKG_CONFIG=/usr/bin/pkg-config to work around the
>    same problem with liblzma as in install_msw.sh. This should become
>    unnecessary soon, but I mention it for completeness if you want to test
>    this right now.

It should now be unnecessary.

> 5. The directory /opt/lmi/mingw/bin had to be added to the PATH for
>    xsltproc.

Fixed.

> 6. "system_test" doesn't work, but this is expected.

Yes. Probably I should put some nonproprietary testdecks in the public
git repository, so that this would just work. But not today.

>  Beyond that, there are some errors in the log, but I don't know if they're
> expected or not: as I had already complained about the unit_tests target,
> there is too much output and no summary at the end allowing to see at a
> glance whether the execution was successful or not.

The idea is that all unit tests succeed all the time, so filtering out
everything that worked correctly leaves nothing: "no news is good news".

> Some suspicious
> extracts from nychthemeral_test log:
> 
>       # unit tests
> 
>       ???? returning with error code 200
>       ???? 
>       ???? errors detected; see stdout for details
>       ???? returning with error code 200
>       ???? 
>       ???? errors detected; see stdout for details
>       ???? returning with error code 200
>       ???? 
>       ???? errors detected; see stdout for details
>       Binary file (standard input) is the same # note: may be inexact
>       64 tests succeeded
> 
> (note is explained by the fact that this was translated back to English
> from the original message "Двоичный файл (стандартный ввод) совпадает").

Some command like
  $grep -A1 '[?] errors detected' /tmp/lmi/**/logs/unit_tests* 2>&1 |less -S
should identify which tests failed. It might be useful to add something like
that to the script.

>  Another one:
> 
>       # test all valid emission types
> 
>       Unable to parse xml file '/tmp/lmi/tmp/sample.ill': File does not exist.
>       [xml_lmi.cpp : 69]
> 
>       Unable to parse xml file '/tmp/lmi/tmp/sample.cns': File does not exist.
>       [xml_lmi.cpp : 69]
> 
> This is confusing because the file does exist. However running the command
> from the test manually:
> 
>       /opt/lmi/bin/lmi_cli_shared --file=/tmp/lmi/tmp/sample.ill --accept 
> --ash_nazg --data_path=/opt/lmi/data 
> --emit=emit_test_data,emit_spreadsheet,emit_text_stream,emit_custom_0,emit_custom_1
> 
> results in the same error message while copying the file to /opt/lmi/data
> and using --file=sample.ill works fine, so something seems to be fishy
> here, but I haven't had yet time to investigate.

I don't suppose the cause could be a quoting error that I've now fixed, viz.:

-cp --preserve $srcdir/sample.cns $srcdir/sample.ill .
+cp --preserve "$srcdir"/sample.cns "$srcdir"/sample.ill .

>  Next one:
> 
>       # schema tests
> 
>       --- sample.cns  2019-05-07 06:07:05.952257800 +0700
>       +++ sorted.cns  2019-05-07 19:36:31.232571900 +0700
>       ...1200+ lines of diff...
> 
> The new file (sorted.cns) uses DOS EOLs, so diff believes that all the
> lines are different. The same happens to the other files being compared.
> Again, I don't know if this is definitely a problem, but it doesn't seem
> right to report such line-endings-only changes to me.

PATH="/opt/lmi/mingw/bin:$PATH" xsltproc sort_cell_subelements.xsl sample.cns > 
sorted.cns
PATH="/opt/lmi/mingw/bin:$PATH" xsltproc sort_cell_subelements.xsl sample.ill > 
sorted.ill
diff --unified=0 sample.cns sorted.cns
diff --unified=0 sample.ill sorted.ill

I guess an msw 'xsltproc' binary must add carriage returns.
I can remove them.