Re: [Plplot-devel] Planning for the release of 5.13.0

[Arjen M. <Arj...@de...>]

Hi Alan,



Here are some results from my most recent, i.e. yesterday's, testing session.



The three tarballs have names that ought to be self-explanatory.

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, July 19, 2017 1:43 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Planning for the release of 5.13.0
>
> On 2017-07-18 12:36-0000 Arjen Markus wrote:
>
> > I attach three tarballs, resulting from the comprehensive test
...

>
> But after your holiday you should look in detail at the results of those analyses
> below.
>
> I. The noninteractive comprehensive test for Cygwin.
>
> * Find issues
>
> My records indicate you last ran a comprehensive test for Cygwin on 2016-12-15.
> The options for that test were the same as the present ones, and that script was a
> complete success.

...

>
> So the changes from December are the wxwidgets device driver is not present and
> there is also a severe regression in enabled bindings.
>
> Is this exactly the same Cygwin system and launch script that you used before
> when testing just before the release of PLplot-5.12.0?  If so, you should be able to
> replicate those good December results by switching to PLplot-5.12.0 (e.g., by
> running
>
It appears that when you add a package to the Cygwin installation, an update follows for all the packages that are already present. This led to me having to adjust the location where the Ada stuff is to be found (change in version). I also had to add a few Python packages (transition from Python 2 to Python 3).

Unfortunately, the new Ada packages result in a problem with multiply defined symbols - see the corresponding tarball. So I had to remove that from the test (by not expanding/explicitly setting the CMAKE_LIBRARY_PATH environment variable).

As this took quite some time, I have not had a look at the reason the wxWidgets component was rejected. That is an issue for the coming days.

>
> * Build error in the CMake-based build tree for the installed examples
>
...
>
> make[3]: *** [c/CMakeFiles/x04c.dir/build.make:104: c/x04c.exe] Error 1
>
> but no accompanying diagnostic error message from gcc itself.
>

I have not seen that in the tests from yesterday. Which is an indication of something. Something to watch out for.

>
> II. The noninteractive comprehensive test for MinGW-w64/MSYS2
>
> * Find issues:
>
> DRIVERS_LIST: cairo;mem;ntk;null;pdf;ps;svg;wingcc;wxwidgets;xfig
>
>
> ENABLE_ada:             OFF
> ENABLE_d:               OFF
> ENABLE_java:            OFF
> ENABLE_ocaml:           OFF
> ENABLE_octave:          OFF
> ENABLE_pdl:             OFF
> ENABLE_qt:              OFF
> ENABLE_pyqt4:           OFF
> ENABLE_pyqt5:           OFF
> ENABLE_itcl:            OFF
> ENABLE_itk:             OFF
>
> The only good historical comparison we have to these results is Greg's (see
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>).
>
> where ada, d, java, ocaml, octave, pyqt4, itcl, and itk were not present in the tests
> for various reasons.  So the only real regression above from those historical results
> was qt was disabled (because it was not found).  So the above is a quite
> encouraging result but you are not quite there yet.
>
> To resolve that last included component regression, what Qt-related packages (if
> any) have you installed?
>
> If the answer is none, I would preserve your current MinGW-w64/MSYS2 snapshot
> (since a new snapshot might not work at all), modify your automated script to install
> that platform from scratch to include Qt
> (Qt4 is preferred but if packaging conflicts insist you need to use Qt5, then use that
> instead) and run that script to install a new snapshot with its own unique install
> prefix.
>
> Then repeat this test on that new snapshot platform with
> DCMAKE_CXX_FLAGS=-fabi-version=8 adjusted to a new number if that is
> needed).

I have not got Qt installed yet - was concentrating on wxWidgets :). Yet another one to take care of.

>
> * ERROR: Traditional make test_noninteractive failed in the installed examples tree
> (for the nondynamic case)
>
> A google search for the term <"gcc.exe: Bad address"> didn't appear to find
> anything relevant.  (There was one issue in Cygwin for 2012 involving commands
> separated with a semicolon, but we don't use a semicolon in the present case.)
>
I tried the following:

- Run the build command explicitly (it is 1800+ characters long!) - this succeeded without any complaint and the resulting program did its job.

- Run make so that the program would be built. That failed with the "Bad address" message.

My current conclusion is that the length of the command is causing a problem in make. It may just go over some internal edge. There is not much PLplot-ish about this, except for the length of the directory names, it would seem.

>
> III. The interactive comprehensive test for MinGW-w64/MSYS2 that is limited just to
> wxwidgets - and beyond ...
>
All to be looked into still.



DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.