plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff

[Alan W. I. <ir...@be...>]

On 2015-04-05 11:14-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> Attached is the stderr/stdout output from the script.
>
>
>
> The script itself was:
>
>
>
> export PATH=/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/bin:$PATH
>
> export PATH=/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/lib/plplot5.10.0/drivers:$PATH
>
> ../plplot-git/scripts/comprehensive_test.sh --do_test_traditional_install_tree no --do_test_interactive no
>
>
>
> I am not sure if both extensions of the PATH variable are required, but at least with the two it worked. At the very least the second was required.

Although the above brute-force changes to the PATH, may work, there
are not ideal since they impose install-tree results on build-tree
tests.  So to investigate further about why that brute-force method
was required I looked at your script output which
has now given me enough information to confuse me.  :-)

If you look at scripts/comprehensive_test.sh for anything to do with
PATH you should notice logic there that puts the build-tree dll
subdirectory on the PATH when doing build tree tests, but that part of
the PATH is dropped (rightly) for install tree tests where instead
components are added to the PATH so the installed (not build-tree)
dlls will be found and the installed drivers will be found.

That logic works great for me in the MinGW or MinGW/MSYS case.
However, I have now noticed that the if statements that introduce
those PATH manipulations tests whether the generator string is either
"MSYS Makefiles" or "MinGW Makefiles" so the currently logic should
not work at all for Cygwin where the generator string must be "Unix
Makefiles". That is clearly a bug in the script that should be fixed
so you don't have to use the brute-force approach above.

The confusing part for me is I would have predicted that
none of those PATH manipulations would work on Cygwin, yet your
script output clearly says

Prepend
/cygdrive/d/plplot-svn/plplot-git/../comprehensive_test_disposeable/nondynamic/install_tree/bin
to the original PATH

which means the script executed logic in what I think would be an
impossible if block to access under Cygwin.  Later on, it did not
exercise the if block with further PATH logic which is the reason you
had to use the above brute-force method.  Anyhow, the point is
the current logic for deciding whether to do PATH manipulations
is problematic.

I think the solution is to drop this problematic logic completely and
instead introduce one more option to the script called
--manipulate_PATH which defaults to no but which Windows platform
users should specify as yes. But I will deal with that issue
post-release, and for now the Cygwin results you have obtained with
the above brute-force approach are good enough.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. I. <ir...@be...>]

On 2015-04-05 01:17-0700 Alan W. Irwin wrote:

> On 2015-04-04 23:11-0700 Greg Jung wrote:
>
>> afaict these environment variables are essential for plots:
>>
>> PLPLOT_DRV_DIR=/usr/local/lib/plplot5.10.0/drivers
>> PLPLOT_HOME=/usr/local/share/plplot5.10.0/
>>
>> DRV_DIR for dynamic loading, to get the driver_info files (.dll files
>> are to be pick
>> up in PATH) and PLPLOT_HOME for support files:
>
> Our build system has long (since 2000 or so) superseded those
> variables which are leftovers from the days when we essentially had no
> build system at all. So setting those varaiables should _never_ be
> needed. For example, I don't use them for any of my successful
> comprehensive testing of PLplot on the Linux and MinGW/MSYS platforms.
> Furthermore, they could introduce problems for your comprehensive testing
> issues on Cygwin. For example, the comprehensive testing script uses
> its own distinct build tree and install tree so using those variables
> to point to results from an entirely different install tree could
> introduce inconsistencies and also pollute build-tree results with
> install-tree results.  So my strong advice is to drop both
> PLPLOT_DRV_DIR and PLPLOT_HOME completely on all platforms with the
> possible exception of the advice Arjen gave to work around what I
> consider to be a bug in recent classical MSYS.
>
> My guess is you are following some severely dated documentation that still
> mentions PLPLOT_DRV_DIR and PLPLOT_HOME.  Could you tell me where that
> documentation is so I can update it to the post-2000 era?
>
> Thanks very much for including the script output in the tarball. The
> error occurred in the first attempt to run make.  So if you look at
> make.out it obviously has something to do with cairo so try removing
> all the cairo device drivers from the test (using
> -DDEFAULT_NO_CAIRO_DEVICES=ON which is much more convenient
> than setting all those -DPLD variables assocated with the many
> different cairo devices to
> OFF) and run the script again.

@Greg:

There is one issue with your script output that concerns me.  To quote
the relevant section from plplotcygwin.out

ctest_command=ctest
build_command=make
cmake_command=cmake -DENABLE_qt=OFF -DENABLE_wxwidgets=OFF -DPLD_wxwidgets=OFF
traditional_build_command=make

That cmake_command is not output from the script so I assume you
inserted that to show how you aliased cmake.  Thanks for that
additional information, but that change to the cmake command will
at minimum generate warnings (when cmake should be run without options
at all for the CMake-based build of the installed examples) 
and may generate subtle errors.

Instead you should simply use the script option

--cmake_added_options \
"-DENABLE_qt=OFF -DENABLE_wxwidgets=OFF -DPLD_wxwidgets=OFF"

and the script will use those options when necessary and drop them
when they should not be used.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff

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

Hi Alan,



I had some time today, so I decided to put some effort into the comprehensive test for MinGW/MSYS. Please see the attached tarball. Things are looking good, even though this case requires a wee bit of massaging.



Regards,



Arjen




From: Arjen Markus [mailto:Arj...@de...]
Sent: Sunday, April 05, 2015 1:14 PM
To: Alan W. Irwin; Greg Jung
Cc: PLplot development list
Subject: Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff


Hi Alan,



Attached is the stderr/stdout output from the script.



The script itself was:



export PATH=/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/bin:$PATH

export PATH=/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/lib/plplot5.10.0/drivers:$PATH

../plplot-git/scripts/comprehensive_test.sh --do_test_traditional_install_tree no --do_test_interactive no



I am not sure if both extensions of the PATH variable are required, but at least with the two it worked. At the very least the second was required.


Regards,

Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> @Arjen: but I would appreciate you finishing your Cygwin report before the release
> with the requested script output since that report and my forthcoming MinGW/MSYS
> one will likely be the only Windows reports we will have at release time unless Greg
> can figure out what is happening for his own Cygwin case and/or the new (to us)
> MSYS2 platform before release.
>
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.
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.

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff

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

Hi Alan,



Attached is the stderr/stdout output from the script.



The script itself was:



export PATH=/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/bin:$PATH

export PATH=/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/lib/plplot5.10.0/drivers:$PATH

../plplot-git/scripts/comprehensive_test.sh --do_test_traditional_install_tree no --do_test_interactive no



I am not sure if both extensions of the PATH variable are required, but at least with the two it worked. At the very least the second was required.


Regards,

Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> @Arjen: but I would appreciate you finishing your Cygwin report before the release
> with the requested script output since that report and my forthcoming MinGW/MSYS
> one will likely be the only Windows reports we will have at release time unless Greg
> can figure out what is happening for his own Cygwin case and/or the new (to us)
> MSYS2 platform before release.
>


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.

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. I. <ir...@be...>]

On 2015-04-04 23:11-0700 Greg Jung wrote:

> afaict these environment variables are essential for plots:
>
> PLPLOT_DRV_DIR=/usr/local/lib/plplot5.10.0/drivers
> PLPLOT_HOME=/usr/local/share/plplot5.10.0/
>
> DRV_DIR for dynamic loading, to get the driver_info files (.dll files
> are to be pick
> up in PATH) and PLPLOT_HOME for support files:

Our build system has long (since 2000 or so) superseded those
variables which are leftovers from the days when we essentially had no
build system at all. So setting those varaiables should _never_ be
needed. For example, I don't use them for any of my successful
comprehensive testing of PLplot on the Linux and MinGW/MSYS platforms.
Furthermore, they could introduce problems for your comprehensive testing
issues on Cygwin. For example, the comprehensive testing script uses
its own distinct build tree and install tree so using those variables
to point to results from an entirely different install tree could
introduce inconsistencies and also pollute build-tree results with
install-tree results.  So my strong advice is to drop both
PLPLOT_DRV_DIR and PLPLOT_HOME completely on all platforms with the
possible exception of the advice Arjen gave to work around what I
consider to be a bug in recent classical MSYS.

My guess is you are following some severely dated documentation that still
mentions PLPLOT_DRV_DIR and PLPLOT_HOME.  Could you tell me where that
documentation is so I can update it to the post-2000 era?

Thanks very much for including the script output in the tarball. The
error occurred in the first attempt to run make.  So if you look at
make.out it obviously has something to do with cairo so try removing
all the cairo device drivers from the test (using
-DDEFAULT_NO_CAIRO_DEVICES=ON which is much more convenient
than setting all those -DPLD variables assocated with the many
different cairo devices to
OFF) and run the script again.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Greg J. <gv...@gm...>]

afaict these environment variables are essential for plots:

PLPLOT_DRV_DIR=/usr/local/lib/plplot5.10.0/drivers
PLPLOT_HOME=/usr/local/share/plplot5.10.0/

DRV_DIR for dynamic loading, to get the driver_info files (.dll files
are to be pick
up in PATH) and PLPLOT_HOME for support files:
greg@Homerw7 /d/bld
$ ls $PLPLOT_DRV_DIR
cairo.dll          null.dll          qt.dll           wxwidgets.dll
      xwin.dll
cairo.driver_info  null.driver_info  qt.driver_info
wxwidgets.driver_info  xwin.driver_info
mem.dll            ps.dll            svg.dll          xfig.dll
mem.driver_info    ps.driver_info    svg.driver_info  xfig.driver_info

greg@Homerw7 /d/bld
$ ls $PLPLOT_HOME
cglobe.map                cmap0_white_bg.pal     cmap1_gray.pal
examples     usa.map
cmap0_alternate.pal       cmap1_blue_red.pal     cmap1_highfreq.pal
globe.map    usaglobe.map
cmap0_black_on_white.pal  cmap1_blue_yellow.pal  cmap1_lowfreq.pal   plstnd5.fnt
cmap0_default.pal         cmap1_default.pal      cmap1_radar.pal     plxtnd5.fnt

The WIN32 warning will go away when the cmake_minimum_required() command is
the very first command. (and min is > 2.8.4)

greg@Homerw7 /usr/local/include
$ env | grep PKG
PKG_CONFIG_PATH=/opt/local/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig

The chatter in CMAKE tells you it detects three paths from PKG_CONFIG_PATH
and so it forms CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH with
whatever I've put there; if I had a non-empty LDFLAGS it would add
those to the mix, also.  All in addition to the traditional
list acquired at the outset.

I've now run the test again and it never goes beyond "make" from the
comprehensive test.
It can also have a make problem when run as if to simply build.  It
snags in a file comparison
of the cairo drivers during test_dyndrivers build.
I can however push the make along and complete the build.


Each of the steps in this comprehensive test may take a while....
cmake -DENABLE_qt=OFF -DENABLE_wxwidgets=OFF -DPLD_wxwidgets=OFF in
the build tree
make VERBOSE=1 in the build tree
ERROR: make failed in the build tree

greg@Homerw7 /d/bld/plplot2-cygwin/shared/build_tree
$ tail ../output_tree/make.out
cd /d/bld/plplot2-cygwin/shared/build_tree/drivers &&
/opt/local/bin/cmake.exe -E compare_files
/d/bld/plplot2-cygwin/shared/build_tree/drivers/test_dyndrivers_dir/cairo.driver_info
/d/bld/plplot2-cygwin/shared/build_tree/drivers/cairo.driver_info
Files "/d/bld/plplot2-cygwin/shared/build_tree/drivers/test_dyndrivers_dir/cairo.driver_info"
to "/d/bld/plplot2-cygwin/shared/build_tree/drivers/cairo.driver_info"
are different.
drivers/CMakeFiles/test_cairo_dyndriver.dir/build.make:52: recipe for
target 'drivers/test_dyndrivers_dir/cairo.driver_info' failed
make[2]: *** [drivers/test_dyndrivers_dir/cairo.driver_info] Error 1
make[2]: Leaving directory '/cygdrive/d/bld/plplot2-cygwin/shared/build_tree'
CMakeFiles/Makefile2:2703: recipe for target
'drivers/CMakeFiles/test_cairo_dyndriver.dir/all' failed
make[1]: *** [drivers/CMakeFiles/test_cairo_dyndriver.dir/all] Error 2
make[1]: Leaving directory '/cygdrive/d/bld/plplot2-cygwin/shared/build_tree'
Makefile:147: recipe for target 'all' failed
make: *** [all] Error 2

greg@Homerw7 /d/bld/plplot2-cygwin/shared/build_tree
$ make VERBOSE=1 >& ../output_tree/make1.out &
[1] 5540
then the tail end of make1.out shows completion:

Scanning dependencies of target lena_file
make[2]: Leaving directory '/cygdrive/d/bld/plplot2-cygwin/shared/build_tree'
make -f plplot_test/CMakeFiles/lena_file.dir/build.make
plplot_test/CMakeFiles/lena_file.dir/build
make[2]: Entering directory '/cygdrive/d/bld/plplot2-cygwin/shared/build_tree'
/opt/local/bin/cmake.exe -E cmake_progress_report
/d/bld/plplot2-cygwin/shared/build_tree/CMakeFiles
[100%] Generating lena.pgm
cd /d/bld/plplot2-cygwin/shared/build_tree/plplot_test &&
/opt/local/bin/cmake.exe -E copy_if_different
/d/bld/plplot-5.11/examples/lena.pgm
/d/bld/plplot2-cygwin/shared/build_tree/plplot_test/lena.pgm
make[2]: Leaving directory '/cygdrive/d/bld/plplot2-cygwin/shared/build_tree'
/opt/local/bin/cmake.exe -E cmake_progress_report
/d/bld/plplot2-cygwin/shared/build_tree/CMakeFiles
[100%] Built target lena_file
make[1]: Leaving directory '/cygdrive/d/bld/plplot2-cygwin/shared/build_tree'
/opt/local/bin/cmake.exe -E cmake_progress_start
/d/bld/plplot2-cygwin/shared/build_tree/CMakeFiles 0

greg@Homerw7 /d/bld/plplot2-cygwin/shared/build_tree
So the stuff is built, but I have to test step-by-step.


On Sat, Apr 4, 2015 at 6:00 PM, Alan W. Irwin <ir...@be...> wrote:
> On 2015-04-04 21:27-0000 Arjen Markus wrote:
>
>> I had to suppress the test_interactive part as well as the traditional
>> build, but then it finished all right. See the attached tgz-file for the
>> details.
>
>
> I agree that limited Cygwin result looks good (other than the
> test_interactive and traditional parts). When time permits
> post-release it would be good to expand this limited Cygwin result to
> more components (via installing them on Cygwin) and also sorting out
> the problems for the interactive and traditional parts of the test.
> But for this release it shows at least these limited components work
> for all our build configurations on Cygwin which is a great relief to
> me as release manager after nothing worked for Greg.
>
> To finish this off so I can post this result in the wiki for this
> release could you also please send the script stderr and stdout output
> that is normally sent to the screen?
>
> To repeat what I told Greg recently, you can capture that script output with
> e.g.,
>
> scripts/comprehensive_test.sh <-- options you used for that script> \
>>
>> & comprehensive_test.sh.out
>
>
> Note that command will hang initially until you answer the question at
> the end of comprehensive_test.sh.out that would ordinarily be sent to
> the screen for the case where script output was not redirected (by
> ">&") to comprehensive_test.sh.out.
>
> Thanks.
>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff

[Alan W. I. <ir...@be...>]

To Greg and Arjen:

There is something for both of you here.

On 2015-04-04 21:46-0700 Greg Jung wrote:

> I've booted over to windows, so it'll be a while b4 I do more Suse.

@Greg:

Well, as you can see from the updated release notes (README.release) I
refer to the wiki for the test reports so if the OpenSUSE report is
filled in a few days after the release it is no big deal since there
is already my two Debian reports there to cover the Linux case, and
I am hoping Andrew will contribute some Linux reports there as
well.

@Arjen: but I would appreciate you finishing your Cygwin report before
the release with the requested script output since that report and my
forthcoming MinGW/MSYS one will likely be the only Windows reports we
will have at release time unless Greg can figure out what is happening
for his own Cygwin case and/or the new (to us) MSYS2 platform before
release.

[out of order]
> Hey, why isn't wxwidget driver shut off (as is qt) when ENABLE_wxwidget=OFF?

The ENABLE for is reserved for libraries, and the PLD form is reserved
for devices.  The qt devices depends on the plplotqt library so if you
disable that library with ENABLE_qt=OFF, all the devices get disabled
as well as a side effect.  The wxwidgets device does not depend on the
plplotwxwidgets library so you have to use both the ENABLE and PLD
forms to turn off everything related to wxwidgets.

> There really is hardly any info being relayed to the screen, except progress
> (ie "ctest -j4 in the build directory"). but ok.

@ Greg and Arjen:

Actually, the script output gives a complete summary of all options
plus a detailed progress report.  All that information is useful to
me both when things go go wrong (so I can advise you) and when
things go right (so I can summarize the result for our wiki).

> I tried to redirect once, then realized it needed my input.  When I tried
> that tho I ended up in some sort of loop with "y" scrolling the screen.
> I think maybe we should pipe it to "tee" and that would solve the confusion.
>  <script> | tee scriptoutput.out should work.

Good idea, but you need to capture both stdout and stderr so I suggest both of
you modify that idea slightly to

<script> |& tee scriptoutput.out

instead.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. I. <ir...@be...>]

On 2015-04-04 21:27-0000 Arjen Markus wrote:

> I had to suppress the test_interactive part as well as the traditional build, but then it finished all right. See the attached tgz-file for the details.

I agree that limited Cygwin result looks good (other than the
test_interactive and traditional parts). When time permits
post-release it would be good to expand this limited Cygwin result to
more components (via installing them on Cygwin) and also sorting out
the problems for the interactive and traditional parts of the test.
But for this release it shows at least these limited components work
for all our build configurations on Cygwin which is a great relief to
me as release manager after nothing worked for Greg.

To finish this off so I can post this result in the wiki for this
release could you also please send the script stderr and stdout output
that is normally sent to the screen?

To repeat what I told Greg recently, you can capture that script output with e.g.,

scripts/comprehensive_test.sh <-- options you used for that script> \
>& comprehensive_test.sh.out

Note that command will hang initially until you answer the question at
the end of comprehensive_test.sh.out that would ordinarily be sent to
the screen for the case where script output was not redirected (by
">&") to comprehensive_test.sh.out.

Thanks.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. I. <ir...@be...>]

On 2015-04-04 19:34-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Saturday, April 04, 2015 9:04 PM
>> To: Arjen Markus
>> Cc: Greg Jung; Phil Rosenberg; Jim Dishaw; PLplot development list
>> Subject: RE: Release status: call for comprehensive testing: Cygwin
>>
>> Hi Arjen:
>>
>> It is very encouraging from my release manager perspective that all components of
>> PLplot that you have enabled on Cygwin appear to be working for the shared case
>> so long as you exclude the traditional build of the installed examples.  >From the
>> output that you attached it appears a number of different things went wrong with that
>> traditional build and test of the installed examples.  We can address those post-
>> release.
>>
>>
>> @Greg
>>
>> This (mostly) good result from Arjen on Cygwin obviously is sharply in contrast with
>> your own results where not even ctest worked on that platform.  Therefore, I suggest
>> you get in touch with Arjen to figure out exactly what he did.  Then following that
>> procedure rigourously should give you similar good results, and probably even more
>> importantly we should be able to document exactly what you did that should be
>> avoided by others on Cygwin when they are running scripts/comprehensive_test.sh.
>>

> Alan, are you sure it's Cygwin and not MSYS/MinGW where Greg's problems occur?

On Cygwin even his initial make fails to build properly so clearly he
is doing something on that platform that you are sucessfully avoiding.
My very initial speculation there was he was not setting the environment
variable correctly to tell CMake how to correctly interpret WIN32
and CYGWIN on his Cygwin platform, and that may still be the issue for
him.

To keep topics straight the rest of this (other than the last
sentence) is about MSYS and MSYS2.

On MSYS2 (I cannot recall whether Greg has tried MSYS) make works, but
ctest completely fails at run-time.

I have seen some strange effects myself for that platform [MinGW/MSYS], unfortunately. I have to set:
>
> set PLPLOT_DRV_DIR=.../drivers
>
> that is set that environment variable to the directory that holds the *.drvinfo files, besides prepending the PATH variable with the directory containing the DLLs, even though things are running in the build tree. I think that is the same problem as Greg is experiencing with his MSYS/MinGW set-up.

The key code in question here is src/ltdl_win32.c where a call to
LoadLibraryA dynamically loads the devices on Windows platforms. I
have looked the documentation of that function at
<https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx>.
There is says for both LoadLibrary (what we used before) and
LoadLibraryA that "... uses a standard search strategy to find the
module; for more information, see the Remarks." Those remarks then
refer to
<https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx>
where it says (item 6 in the order of what is searched for) that "The
directories that are listed in the PATH environment variable." So from
that you would conclude that if the devices are in the dll
subdirectory, and that subdirectory is on your PATH, then the dll's
corresponding to the device drivers should be found and ltdl_win32.c
should just work.  However, I must say that long Microsoft documentation
trail has so many "ifs, and, and buts" that it leaves a lot of room
for doubt that this whole process will work, and it is possible that
the latest MSYS that you are using deliberately interferes with this
process.

So proceeding by experiment, the whole process has worked both for you
and me historically when the call was to LoadLibrary, and I will soon
be testing the current code where the call is to LoadLibraryA.  But from
that documentation trail, I don't think that distinction matters so
I expect it will continue to work for me (since I continue to
use exactly the same MSYS and Wine that worked for me before), and
the issue may be in the more modern version of the classical MSYS that
you are trying now.

@Greg:

For the MSYS2 case, you first might want to temporarily try changing the
cmake logic in cmake/modules/drivers.cmake that currently reads

if(ENABLE_DYNDRIVERS AND WIN32_OR_CYGWIN)
   if(NOT CYGWIN)
       set(LTDL_WIN32 ON)
       set(LTDL_INCLUDE_DIR ${CMAKE_SOURCE_DIR}/include)
    endif(NOT CYGWIN)
endif(ENABLE_DYNDRIVERS AND WIN32_OR_CYGWIN)

to

set(LTDL_WIN32)

i.e., to disable using the src/ltdl_win32.c code for the MSYS2 platform.
The above full logic disables that approach just for the Cygwin case on
Windows, and it is possible it should also be disabled for MSYS2.

@Arjen:

For my own MinGW/MSYS tests I am going to try both enabling and
disabling the src/ltdl_win32.c approach to see whether both
work for me.  If so, I will permanently change to disabling
src/ltdl_win32.c for the (classical) MSYS case since that
approach might work for you as well.

Anyhow, I will let you know how that goes, and I hope to hear back from
you how your additional Cygwin testing has gone.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

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

Hi Alan,



I had to suppress the test_interactive part as well as the traditional build, but then it finished all right. See the attached tgz-file for the details.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Once you have a clean result please post all relevant results here (i.e., attach a
> compressed version of the output from the script, and also attach a compressed
> tarball of _just_ the directories comprehensive_test_disposeable/shared/output_tree
> comprehensive_test_disposeable/nondynamic/output_tree
> comprehensive_test_disposeable/static/output_tree) so I can use those data to
> summarize the good and dropped part of your comprehensive test on the wiki.
>


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.

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Saturday, April 04, 2015 9:04 PM
> To: Arjen Markus
> Cc: Greg Jung; Phil Rosenberg; Jim Dishaw; PLplot development list
> Subject: RE: Release status: call for comprehensive testing: Cygwin
>
> Hi Arjen:
>
> It is very encouraging from my release manager perspective that all components of
> PLplot that you have enabled on Cygwin appear to be working for the shared case
> so long as you exclude the traditional build of the installed examples.  >From the
> output that you attached it appears a number of different things went wrong with that
> traditional build and test of the installed examples.  We can address those post-
> release.
>
>
> @Greg
>
> This (mostly) good result from Arjen on Cygwin obviously is sharply in contrast with
> your own results where not even ctest worked on that platform.  Therefore, I suggest
> you get in touch with Arjen to figure out exactly what he did.  Then following that
> procedure rigourously should give you similar good results, and probably even more
> importantly we should be able to document exactly what you did that should be
> avoided by others on Cygwin when they are running scripts/comprehensive_test.sh.
>
Alan, are you sure it's Cygwin and not MSYS/MinGW where Greg's problems occur? I have seen some strange effects myself for that platform, unfortunately. I have to set:

set PLPLOT_DRV_DIR=.../drivers

that is set that environment variable to the directory that holds the *.drvinfo files, besides prepending the PATH variable with the directory containing the DLLs, even though things are running in the build tree. I think that is the same problem as Greg is experiencing with his MSYS/MinGW set-up.

Regards,

Arjen



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.

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff

[Alan W. I. <ir...@be...>]

On 2015-04-04 11:43-0700 Greg Jung wrote:

> I've been gzip-tarring the whole output directories as I get them, I
> dont know where else to find outputs.

Hi Greg:

Those *.out files are quite useful, but to completely understand what you
did, I also need the stderr and stdout output from the script itself
that normally just gets printed out to your screen.

Capture both stderr and stdout by running

scripts/comprehensive_test.sh >& comprehensive_test.sh.out

(Note that command will just hang until you remember to respond to the question that will be at
the end of that output file when you first run that command).

My diagnosis of your cmake.out file shows that ENABLE_wxwidgets was
OFF, but the wxwidgets device was still there. To suppress both, you
must specify both -DENABLE_wxwidgets=OFF and -DPLD_wxwidgets=OFF with
the appropriate script option, and I believe you only specified the
first of those (although the script output from now on will help me to
confirm exactly what you specify each time).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. I. <ir...@be...>]

On 2015-04-04 15:31-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>>  -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> @Arjen, Phil, and Jim:
>>
>> As release manager, that latter possibility of a regression in comprehensive testing
>> on the Cygwin platform really concerns me, and I ask at least one of you guys to
>> confirm/deny that possibility by simply running scripts/comprehensive_test.sh on
>> Cygwin with appropriate environmental variables set (ideally with a "source"
>> script that you run from using the bash "source" command to keep everything easily
>> and automatically reproducible) to setup the Cygwin platform for the PLplot build and
>> test.
>>
>> N.B. I emphasize sourcing a "source" script from bash and running
>> scripts/comprehensive_test.sh as opposed to piece-meal tests done by hand since
>> (a) the script result should be completely automated and reproducible if you have set
>> up the platform properly, and (b) comprehensive testing is so much more powerful
>> than piece-meal tests.
>> So I would appreciate hearing from any of you quickly if you are in a good position to
>> run that script.
>>
> I ran scripts/comprehensive_test.sh with no argument and prepending two directories to the PATH environment variable (.../shared/bin and .../shared/lib/plplot5.10.0/drivers) and everything ran until the "traditional make" step, see the attached output. The error seems to be specific to Cygwin - the names of the libraries.
>
> The other steps did not reveal any problems, as far as I can tell from an examination of the output files.

Hi Arjen:

It is very encouraging from my release manager perspective that all
components of PLplot that you have enabled on Cygwin appear to be
working for the shared case so long as you exclude the traditional
build of the installed examples.  From the output that you attached
it appears a number of different things went wrong with that
traditional build and test of the installed examples.  We can address
those post-release.

For now, please continue the process before this release deadline by using the
appropriate documented arguments of scripts/comprehensive_test.sh
until you get a complete run of the script with no errors.  Then we
will know where we stand, i.e., exactly which parts of the
comprehensive test work on Cygwin and which do not, and we can post
those definitive results on our wiki and refer to them in the release
notes.

The required documentation of the script is found by using the --help
argument, and it follows from that and the number of bad results you
obtained for the make + pkg-config traditional build of the installed
examples that you should re-run the script using the arguments
"--do_test_traditional_install_tree no". Hopefully, that will be
enough to give you a clean result, but if not, please continue by
re-running the script with more removed from the tests.

Once you have a clean result please post all relevant results here
(i.e., attach a compressed version of the output from the script, and
also attach a compressed tarball of _just_ the directories
comprehensive_test_disposeable/shared/output_tree
comprehensive_test_disposeable/nondynamic/output_tree
comprehensive_test_disposeable/static/output_tree) so I can use those
data to summarize the good and dropped part of your comprehensive test
on the wiki.

@Greg

This (mostly) good result from Arjen on Cygwin obviously is sharply in
contrast with your own results where not even ctest worked on that
platform.  Therefore, I suggest you get in touch with Arjen to figure
out exactly what he did.  Then following that procedure rigourously
should give you similar good results, and probably even more
importantly we should be able to document exactly what you did that
should be avoided by others on Cygwin when they are running
scripts/comprehensive_test.sh.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff

[Greg J. <gv...@gm...>]

I've been gzip-tarring the whole output directories as I get them, I
dont know where else to find outputs.  This last test looks 100% but
again
the script didn't exit normally but only, after a half hour of no activity,
from a ^\.

On Sat, Apr 4, 2015 at 2:14 AM, Alan W. Irwin <ir...@be...> wrote:
> On 2015-04-03 23:32-0700 Greg Jung wrote:
>
>> "cmake -DENABLE_qt=OFF" and yes it is running like gangbusters, the
>> strip-chart demo on wxPL is interminable ...
>
>
> Same here and this issue for new wxwidgets is also mentioned in bug
> 151.  However, if you had followed my previous advice about how to get
> by example 17 without disrupting the test script, this would not be an
> issue.
>
> You also did not include the many-times requested output from
> scripts/comprehensive_test.sh. That makes it difficult for me to know
> exactly what is happening, but if you look for errors in the report
> you sent, you only got through one-third of the test again. Looking
> further, there is a segmentation fault for c++/wxPLplotDemo.  So to
> avoid that serious run-time issue disable wxwidgets (which means you
> don't have to look up my advice with regard to getting through example
> 17 for wxwidgets, :-) ) and please try again to complete this
> comprehensive test.  And so on, if you run into any more showstopping
> errors like that one.
>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

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

Hi Alan,



>  -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> @Arjen, Phil, and Jim:
>
> As release manager, that latter possibility of a regression in comprehensive testing
> on the Cygwin platform really concerns me, and I ask at least one of you guys to
> confirm/deny that possibility by simply running scripts/comprehensive_test.sh on
> Cygwin with appropriate environmental variables set (ideally with a "source"
> script that you run from using the bash "source" command to keep everything easily
> and automatically reproducible) to setup the Cygwin platform for the PLplot build and
> test.
>
> N.B. I emphasize sourcing a "source" script from bash and running
> scripts/comprehensive_test.sh as opposed to piece-meal tests done by hand since
> (a) the script result should be completely automated and reproducible if you have set
> up the platform properly, and (b) comprehensive testing is so much more powerful
> than piece-meal tests.
> So I would appreciate hearing from any of you quickly if you are in a good position to
> run that script.
>
I ran scripts/comprehensive_test.sh with no argument and prepending two directories to the PATH environment variable (.../shared/bin and .../shared/lib/plplot5.10.0/drivers) and everything ran until the "traditional make" step, see the attached output. The error seems to be specific to Cygwin - the names of the libraries.

The other steps did not reveal any problems, as far as I can tell from an examination of the output files.

Regards,

Arjen





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.

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

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

Hi Alan, Greg,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> @Greg: You have much more experience with Cygwin than I do (since my actual
> experience is zero).  Nevertheless, historically there has been lots of warnings on
> the CMake list that Cygwin users _must_ use the Cygwin version of CMake and not
> the generic Windows version.  So because Arjen has had success with
> comprehensive testing on Cygwin in the past with that approach, and you are
> currently not having such success with a generic version of CMake rather than the
> Cygwin version, I drew the conclusion you should try the Cygwin version of CMake.
>
> @Arjen:
>
> Do you still use the Cygwin version of CMake for your Cygwin tests or is that
> historical advice no longer relevant so that the generic Windows version of CMake
> that you can download for Kitware gives good results for you?
>
Under Cygwin I always use the Cygwin version of CMake. I simply do not know if that is still necessary and whether the generic Windows version would work as well. It is something that can easily be tested of course.

Regards,

Arjen



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.

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff

[Alan W. I. <ir...@be...>]

On 2015-04-03 23:32-0700 Greg Jung wrote:

> "cmake -DENABLE_qt=OFF" and yes it is running like gangbusters, the
> strip-chart demo on wxPL is interminable ...

Same here and this issue for new wxwidgets is also mentioned in bug
151.  However, if you had followed my previous advice about how to get
by example 17 without disrupting the test script, this would not be an
issue.

You also did not include the many-times requested output from
scripts/comprehensive_test.sh. That makes it difficult for me to know
exactly what is happening, but if you look for errors in the report
you sent, you only got through one-third of the test again. Looking
further, there is a segmentation fault for c++/wxPLplotDemo.  So to
avoid that serious run-time issue disable wxwidgets (which means you
don't have to look up my advice with regard to getting through example
17 for wxwidgets, :-) ) and please try again to complete this
comprehensive test.  And so on, if you run into any more showstopping
errors like that one.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Release status: updated release notes

[Alan W. I. <ir...@be...>]

I have just (commit dadae4a) updated the 5.11.0 release notes
(contained in the README.release file) based on skimming the commit
messages for the ~500 commits we have done since the release of 5.10.0.

Could everyone who made commits in this release cycle review these
updated notes and commit additional changes to them if required?

@Phil:

That request is especially addressed to you since I had a lot of
trouble trying to write up your work on new wxwidgets. I based that
write up on what was said on the mailing list, but I very likely
missed or misstated some point concerning new wxwidgets so your
further help with that part of the writeup would be appreciated.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff

[Greg J. <gv...@gm...>]

the shapelib puzzle was solved, I had just installed under root, and
the access mode of the copied file didn't allow the user-access
account to read, so find_path didn't work -  When I did a CHMOD it
worked for shapelib.

I see the operative qhull_a is plgridd.c:#include <qhull/qhull_a.h>
so in fact FindQHULL should stay as it was
and I need to rename that directory; call it a bug in the qhull install.

I think I installed what I hope is the D compiler
"zypper in dmd-2.067.0-0.openSUSE.x86_64.rpm"
I'll log out and back in to make sure the install applies.

showing off a little, I have over 276,000 files under /usr and over
5000 have "java" in the path:
GDL> ff=file_search("/usr","*",count=nfile) & print,nfile
      276744
GDL> ps=strpos(ff,'java') & k=where(ps ne -1,np) & print,np
        5650
GDL> print,ff[k[0:3]]
/usr/bin/gjavah /usr/bin/gjavah-4.8 /usr/bin/java /usr/bin/javaws
GDL> print,ff[k[4:9]]
/usr/include/c++/4.8/gcj/javaprims.h /usr/include/c++/4.8/gnu/java
/usr/include/c++/4.8/gnu/java/awt
/usr/include/c++/4.8/gnu/java/awt/AWTUtilities.h
/usr/include/c++/4.8/gnu/java/awt/BitMaskExtent.h
/usr/include/c++/4.8/gnu/java/awt/BitwiseXORComposite.h
but it looks like my jvm is sick:
GDL> $
greg@linux-gc09:/home> env | grep JAV
JAVA_BINDIR=/usr/lib64/jvm/jre/bin
JAVA_HOME=/usr/lib64/jvm/jre
JAVA_ROOT=/usr/lib64/jvm/jre
greg@linux-gc09:/home> java -v
Unrecognized option: -v
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
--------------
OK I've re-run, and everything but qt, java, and D-compiler looks good.
INSTALL_BUILD_TREE = /home/plplot5-opensuse13.2/shared/install_build_tree
  then, I've copied the modified script over so that i can run
"cmake -DENABLE_qt=OFF" and yes it is running like gangbusters, the
strip-chart demo on wxPL is interminable ...


On Fri, Apr 3, 2015 at 9:26 PM, Alan W. Irwin <ir...@be...> wrote:
> On 2015-04-03 18:39-0700 Greg Jung wrote:
>
>>  My Linux system has only been around a short while, I've had to
>> scrap the Linux portion of my 'puter a few times.  So my initial
>> load-up didn't include the less-used items.  But its no problem to
>> bring them in,
>> especially those I can download directly.
>>
>> My previous tests did not include qt, qhull, shapelib, ada, java.
>> Running comprehensive_tests.sh the first time resulted in full
>> success, so that my screen was teeming with wxView windows which I cut
>> short.  As I bring
>> more elements to the mix, I presume the failures are triggering a quit
>> in the script; i.e. it hasn't appeard complete even though my build
>> may be as good or better than before.
>
>
> [out of order]
>>
>> I've also just installed java and that hasn't been recognized in
>> cmake/plplot build.
>
>
> Here is what I have done for Debian stable to solve such a java issue:
>
> # The debian gcj-4.7-jdk package (or its dependencies) has
> # some peculiar locations for java components so CMake needs
> # some help in finding those.
> export CMAKE_INCLUDE_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/include
> export CMAKE_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/gcj-4.7-13
>
> You may need something similar.  Note this assumes this is the
> first time you export and define these environment variables (which
> is why I have responded out of order).  Also, see further comments
> about CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH below.
>
>>
>> Current status: {plplot}/cmake/FindQHULL needs modification or it will
>> never bring the current qhull in.  I installed qhull from source today
>> and it created a /usr/local/include/libqhull where qhull_a.h is to be
>> found:
>> There is also a libqhullcpp.
>> Using this solves that:
>> find_path(
>>  QHULL_INCLUDE_DIR
>>    qhull_a.h
>>  PATHS
>>  /usr/local/include/libqhull /usr/include/libqhull
>>  /usr/local/include/qhull /usr/include/qhull
>> )
>>
>> shapelib: CMAKE doesn't find it:
>>
>> modules/FindShapelib.cmake:find_path(SHAPELIB_INCLUDE_DIR shapefil.h)
>> so I'll try:
>> find_path(SHAPELIB_INCLUDE_DIR
>>      shapefil.h
>>    PATHS
>>      /usr/local/include /usr/include
>>        )
>> message(STATUS " Tried to find SHAPELIB: ${SHAPELIB_INCLUDE_DIR}")
>>
>> despite the effort, it doesn't work:
>>
>> Tried to find SHAPELIB: SHAPELIB_INCLUDE_DIR-NOTFOUND
>>
>> WARNING: SHAPELIB not found. Setting HAVE_SHAPELIB to OFF.
>
>
> Here is what I do to solve similar issues for finding both qhull
> and shapelib:
>
> export CMAKE_INCLUDE_PATH #if not exported before (see java case above)
> export CMAKE_LIBRARY_PATH #if not exported before (see java case above)
> # Special qhull install:
> CMAKE_INCLUDE_PATH=\
> /home/software/qhull/install/include":$CMAKE_INCLUDE_PATH"
> CMAKE_LIBRARY_PATH=\
> /home/software/qhull/install/lib":$CMAKE_LIBRARY_PATH"
>
> # Special shapelib install:
> CMAKE_INCLUDE_PATH=\
> /home/software/shapelib/install/include":$CMAKE_INCLUDE_PATH"
> CMAKE_LIBRARY_PATH=\
> /home/software/shapelib/install/lib":$CMAKE_LIBRARY_PATH"
>
> This technique should also work fine for you if you adjust
> locations to be correct for your system.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: ctest errors

[Alan W. I. <ir...@be...>]

On 2015-04-03 18:39-0700 Greg Jung wrote:

>  My Linux system has only been around a short while, I've had to
> scrap the Linux portion of my 'puter a few times.  So my initial
> load-up didn't include the less-used items.  But its no problem to
> bring them in,
> especially those I can download directly.
>
> My previous tests did not include qt, qhull, shapelib, ada, java.

I have already commented on the measures you can take so that cmake
will find qhull, shapelib, and java.  To add to those remarks
concerning finding java, from your cmake.out it appears that the java
compiler could not be found.  So in addition to the possible
CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH manipulations I mentioned in
my last post, you likely have to install a development version of java
that includes a java to bytecode compiler such as gcj, and a bytecode
interpreter such as gij.

With regard to the remaining two components, Qt4, and Ada, it appears
our build system found them without trouble.


> Running comprehensive_tests.sh the first time resulted in full
> success, so that my screen was teeming with wxView windows which I cut
> short.  As I bring
> more elements to the mix, I presume the failures are triggering a quit
> in the script; i.e. it hasn't appeard complete even though my build
> may be as good or better than before.

Yes, comprehensive testing typically consists of loading up the
platform and setting environment variables so that all PLplot soft
dependencies are found, doing a comprehensive test to find out what
components of PLplot fail, noting those, and iterating until you have
a list of failing components and a successful complete run of the
script for everything that you did not disable.  If this is a platform
where we have no previous information about comprehensive testing
(SuSe is one of those), then probably all we will do this late in a
release cycle is note (in the Wiki) the components that fail for a
given platform.  Then hopefully after the release if you are
interested in expanding this comprehensive OpenSUSE test for the
benefit of all users of that platform, then one of us can advise you
component by component about what might be going wrong. I have
finished such a process for Debian stable and some time ago and
recently proved there were no regressions in that result, and I did
something similar recently for an epa_built version of PLplot on
Debian stable (and I plan to do a similar test of epa_built
plplot-lite on MinGW/MSYS/Wine.) Andrew has similar good comprehensive
testing results for Debian unstable and Ubuntu.  But it does sound
like OpenSUSE is not in as good shape.  For example, your ctest.out
file clearly shows that anything to do with qt segfaulted on OpenSUSE,
and that is really valuable information for every other OpenSUSE user
of plplot-5.11.0 which I plan to propagate to the wiki.

To make further progress, exclude qt (look in CMakeCache.txt for a
convenient variable to help you do that for every single different qt
device at once) and try running the comprehensive_tests.sh script
again. From your prior results, that run should go to completion of at
least the first (shared) part of the test (and maybe all three parts
of the test if you don't interrupt it) if your introduction of Ada to
the mix and the fixups I suggested for qhull, shapelib, and java for
finding those additional components do not trigger any additional
run-time issues.  But if one of those additional "found" components
fails, document what test failed, exclude it, and continue.

Sorry this is such a long painstaking process, but that is the nature
of the beast when there is no previous group experience with running
scripts/comprehensive_test.sh on the platform of interest (OpenSUSE in
this case).  I honestly thought comprehensive testing on an OpenSUSE
platform loaded up with _all_ PLplot soft dependencies would just sail
through since OpenSUSE is Linux after all, but those segfaults for qt
are a wake-up call that this is not always the case.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff

[Alan W. I. <ir...@be...>]

On 2015-04-03 18:39-0700 Greg Jung wrote:

>  My Linux system has only been around a short while, I've had to
> scrap the Linux portion of my 'puter a few times.  So my initial
> load-up didn't include the less-used items.  But its no problem to
> bring them in,
> especially those I can download directly.
>
> My previous tests did not include qt, qhull, shapelib, ada, java.
> Running comprehensive_tests.sh the first time resulted in full
> success, so that my screen was teeming with wxView windows which I cut
> short.  As I bring
> more elements to the mix, I presume the failures are triggering a quit
> in the script; i.e. it hasn't appeard complete even though my build
> may be as good or better than before.

[out of order]
> I've also just installed java and that hasn't been recognized in
> cmake/plplot build.

Here is what I have done for Debian stable to solve such a java issue:

# The debian gcj-4.7-jdk package (or its dependencies) has
# some peculiar locations for java components so CMake needs
# some help in finding those.
export CMAKE_INCLUDE_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/include
export CMAKE_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/gcj-4.7-13

You may need something similar.  Note this assumes this is the
first time you export and define these environment variables (which
is why I have responded out of order).  Also, see further comments
about CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH below.

>
> Current status: {plplot}/cmake/FindQHULL needs modification or it will
> never bring the current qhull in.  I installed qhull from source today
> and it created a /usr/local/include/libqhull where qhull_a.h is to be
> found:
> There is also a libqhullcpp.
> Using this solves that:
> find_path(
>  QHULL_INCLUDE_DIR
>    qhull_a.h
>  PATHS
>  /usr/local/include/libqhull /usr/include/libqhull
>  /usr/local/include/qhull /usr/include/qhull
> )
>
> shapelib: CMAKE doesn't find it:
>
> modules/FindShapelib.cmake:find_path(SHAPELIB_INCLUDE_DIR shapefil.h)
> so I'll try:
> find_path(SHAPELIB_INCLUDE_DIR
>      shapefil.h
>    PATHS
>      /usr/local/include /usr/include
>        )
> message(STATUS " Tried to find SHAPELIB: ${SHAPELIB_INCLUDE_DIR}")
>
> despite the effort, it doesn't work:
>
> Tried to find SHAPELIB: SHAPELIB_INCLUDE_DIR-NOTFOUND
>
> WARNING: SHAPELIB not found. Setting HAVE_SHAPELIB to OFF.

Here is what I do to solve similar issues for finding both qhull
and shapelib:

export CMAKE_INCLUDE_PATH #if not exported before (see java case above)
export CMAKE_LIBRARY_PATH #if not exported before (see java case above)
# Special qhull install:
CMAKE_INCLUDE_PATH=\
/home/software/qhull/install/include":$CMAKE_INCLUDE_PATH"
CMAKE_LIBRARY_PATH=\
/home/software/qhull/install/lib":$CMAKE_LIBRARY_PATH"

# Special shapelib install:
CMAKE_INCLUDE_PATH=\
/home/software/shapelib/install/include":$CMAKE_INCLUDE_PATH"
CMAKE_LIBRARY_PATH=\
/home/software/shapelib/install/lib":$CMAKE_LIBRARY_PATH"

This technique should also work fine for you if you adjust
locations to be correct for your system.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Release status: call for comprehensive testing: Cygwin

[Alan W. I. <ir...@be...>]

On 2015-04-03 14:06-0700 Greg Jung wrote:

> In Cygwin, I do use the cygwin cmake; but it isn't distributed by
> cygwin, I built it from source.  At one point I tried the windows
> cmake from cygwin and it failed miserably.

@Greg:

Thanks for that clarification.  I agree that cmake built on Cygwin
should work fine to build and test PLplot on Cygwin.  Yet your results
are different from Arjen's historical good comprehensive test results
on Cygwin (where he did use the Cygwin install version of CMake).  So
either that difference is significant (which I agree is unlikely, but
you never know), there is some CMake version issue between the CMake
version you are using and the CMake version that Arjen historically
used (much more likely), something is wrong with your additional setup
on Cygwin (e.g., environment variables that you set that might
interfere with our testing framework, also fairly likely), or else
there is some comprehensive testing regression for PLplot for the
Cygwin platform.

@Arjen, Phil, and Jim:

As release manager, that latter possibility of a regression in
comprehensive testing on the Cygwin platform really concerns me, and I
ask at least one of you guys to confirm/deny that possibility by
simply running scripts/comprehensive_test.sh on Cygwin with
appropriate environmental variables set (ideally with a "source"
script that you run from using the bash "source" command to keep
everything easily and automatically reproducible) to setup the Cygwin
platform for the PLplot build and test.

N.B. I emphasize sourcing a "source" script from bash and running
scripts/comprehensive_test.sh as opposed to piece-meal tests done by
hand since (a) the script result should be completely automated and
reproducible if you have set up the platform properly, and (b)
comprehensive testing is so much more powerful than piece-meal tests.
So I would appreciate hearing from any of you quickly if you are in a
good position to run that script.

Meanwhile, I am going to continue with the release process culminating
(I hope this weekend) with starting scripts/comprehensive_test.sh for
the MinGW/MSYS/Wine case.  That result will take roughly 3 days to
complete (since Wine startup of each command is so much slower than
what happens for Microsoft Windows).  Once I have a good comprehensive
test result on MinGW/MSYS/Wine (likely Tuesday at the earliest) I plan
to go ahead with the release unless one of you confirms Greg's result
that running scripts/comprehensive_test.sh no longer works on Cygwin.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Comprehensive testing: OpenSuse-13.2

[Greg J. <gv...@gm...>]

  My Linux system has only been around a short while, I've had to
scrap the Linux portion of my 'puter a few times.  So my initial
load-up didn't include the less-used items.  But its no problem to
bring them in,
especially those I can download directly.

My previous tests did not include qt, qhull, shapelib, ada, java.
Running comprehensive_tests.sh the first time resulted in full
success, so that my screen was teeming with wxView windows which I cut
short.  As I bring
more elements to the mix, I presume the failures are triggering a quit
in the script; i.e. it hasn't appeard complete even though my build
may be as good or better than before.

Current status: {plplot}/cmake/FindQHULL needs modification or it will
never bring the current qhull in, I installed qhull from source today
and it created a /usr/local/include/libqhull where qhull_a.h is to be
found:
There is also a libqhullcpp.
Using this solves that:
find_path(
  QHULL_INCLUDE_DIR
    qhull_a.h
  PATHS
  /usr/local/include/libqhull /usr/include/libqhull
  /usr/local/include/qhull /usr/include/qhull
)

shapelib: CMAKE doesn't find it:

modules/FindShapelib.cmake:find_path(SHAPELIB_INCLUDE_DIR shapefil.h)
so I'll try:
find_path(SHAPELIB_INCLUDE_DIR
      shapefil.h
    PATHS
      /usr/local/include /usr/include
        )
message(STATUS " Tried to find SHAPELIB: ${SHAPELIB_INCLUDE_DIR}")

despite the effort, it doesn't work:

 Tried to find SHAPELIB: SHAPELIB_INCLUDE_DIR-NOTFOUND

WARNING: SHAPELIB not found. Setting HAVE_SHAPELIB to OFF.


I've also just installed java and that hasn't been recognized in
cmake/plplot build.

greg@linux-gc09:/home/bld/qhull> ls /usr/local/include/
converter.h  libqhull  libqhullcpp  plplot  shapefil.h  udunits2.h
greg@linux-gc09:/home/bld/qhull> ls /usr/local/include/libqhull
geom.h     libqhull.h  poly.h        qh-io.htm     qh-poly.htm
qh-stat.htm  qset.h    user.h
index.htm  mem.h       qh-geom.htm   qh-mem.htm    qh-qhull.htm
qhull_a.h    random.h
io.h       merge.h     qh-globa.htm  qh-merge.htm  qh-set.htm
qh-user.htm  stat.h
greg@linux-gc09:/home/bld/qhull> ls /usr/local/lib
cmake                 libplplotcxx.so.11       libplplotf95.so.11.0.0
     libqhullcpp.a       libqsastime.so
fortran               libplplotcxx.so.11.0.0   libplplot.so
     libqhull_p.so       libqsastime.so.0
libcsirocsa.so        libplplotf95c.so         libplplot.so.12
     libqhull_p.so.6     libqsastime.so.0.0.1
libcsirocsa.so.0      libplplotf95c.so.11      libplplot.so.12.0.1
     libqhull.so         libshp.a
libcsirocsa.so.0.0.1  libplplotf95c.so.11.0.0  libplplotwxwidgets.so
     libqhull.so.6       libudunits2.so
libplf95demolib.a     libplplotf95.so          libplplotwxwidgets.so.0
     libqhullstatic.a    pkgconfig
libplplotcxx.so       libplplotf95.so.11
libplplotwxwidgets.so.0.0.0  libqhullstatic_p.a
greg@linux-gc09:/home/bld/qhull> ls /usr/local/lib/pkgconfig/
plplot-c++.pc  plplot-f95.pc  plplot.pc  plplot-wxwidgets.pc
greg@linux-gc09:/home/bld/qhull> ls /usr/local/lib64/pkgconfig/
ls: cannot access /usr/local/lib64/pkgconfig/: No such file or directory

greg@linux-gc09:/home/bld/qhull> ls /home/plplot-5.11/cmake/modules/Find*
/home/plplot-5.11/cmake/modules/FindAGG.cmake
/home/plplot-5.11/cmake/modules/FindLua.cmake
/home/plplot-5.11/cmake/modules/FindAQT.cmake
/home/plplot-5.11/cmake/modules/FindQHULL.cmake
/home/plplot-5.11/cmake/modules/FindFreetype.cmake
/home/plplot-5.11/cmake/modules/FindShapelib.cmake
/home/plplot-5.11/cmake/modules/FindGD.cmake
/home/plplot-5.11/cmake/modules/FindSWIG.cmake
/home/plplot-5.11/cmake/modules/Findhpdf.cmake
/home/plplot-5.11/cmake/modules/FindVGA.cmake
/home/plplot-5.11/cmake/modules/FindLTDL.cmake
/home/plplot-5.11/cmake/modules/FindwxWidgets.cmake
greg@linux-gc09:/home/bld/qhull> cat
/home/plplot-5.11/cmake/modules/FindQHULL.cmake
# Find qhull header and library.
#

# This module defines the following uncached variables:
#  QHULL_FOUND, if false, do not try to use qhull.
#  QHULL_INCLUDE_DIRS, where to find qhull/qhull_a.h.
#  QHULL_LIBRARIES, the libraries to link against to use the qhull library
#  QHULL_LIBRARY_DIRS, the directory where the qhull library is found.

find_path(
  QHULL_INCLUDE_DIR
    qhull/qhull_a.h
  /usr/local/include
  /usr/include
)

if( QHULL_INCLUDE_DIR )
  find_library(
    QHULL_LIBRARY
    NAMES qhull
    PATHS /usr/local/lib /usr/lib
  )
  if( QHULL_LIBRARY )
    get_filename_component(QHULL_LIBRARY_DIRS ${QHULL_LIBRARY} PATH)
    # Set uncached variables as per standard.
    set(QHULL_FOUND ON)
    set(QHULL_INCLUDE_DIRS ${QHULL_INCLUDE_DIR})
    set(QHULL_LIBRARIES ${QHULL_LIBRARY})
  endif(QHULL_LIBRARY)
endif(QHULL_INCLUDE_DIR)

if(QHULL_FOUND)
  if(NOT QHULL_FIND_QUIETLY)
    message(STATUS "FindQHull: Found both qhull_a.h and libqhull.a")
  endif(NOT QHULL_FIND_QUIETLY)
else(QHULL_FOUND)
  if(QHULL_FIND_REQUIRED)
    message(FATAL_ERROR "FindQHull: Could not find qhull_a.h and/or libqhull.a")
  endif(QHULL_FIND_REQUIRED)
endif(QHULL_FOUND)
greg@linux-gc09:/home/bld/qhull> ls /usr/local/include
converter.h  libqhull  libqhullcpp  plplot  shapefil.h  udunits2.h
greg@linux-gc09:/home/bld/qhull> vi /home/plplot-5.11/cmake/modules/*shap*
greg@linux-gc09:/home/bld/qhull> which java
/usr/bin/java

On Fri, Apr 3, 2015 at 12:26 PM, Alan W. Irwin
<ir...@be...> wrote:
> On 2015-04-02 22:57-0700 Greg Jung wrote:
>
>>
>> In each setup there are naturally missing pieces.
>>>

Re: [Plplot-devel] Release status: call for comprehensive testing: MinGW-w64/MSYS2

[Greg J. <gv...@gm...>]

The cmake I specify for MSYS is a vanilla cmake downloaded from
cmake.org; I use this because all of my other CMakes use scripts I
modified.

Cmake for Msys needs to use msys make, not mingw32-make; otherwise you
want to do a mingw build which involves hiding "sh" from the PATH,
using CMD.exe,  etc. etc. I tried it once it fell pretty quickly.

I really couldn't quote an example where msys(1) is so different from msys2
that msys2 is more unix-like.   Both use the same name-conversion
rules and both use an interface layer to look like linux.  When I
installed msys2
it succeeded in a build that mingw(org)/msys was failing.  Then I
discovered that most of the libraries I was building were already
pre-built and distributed, via the MSYS2/pacman distribution program.

I'm on Linux today, will send interim results under a different subject.

On Fri, Apr 3, 2015 at 12:26 PM, Alan W. Irwin
<ir...@be...> wrote:
> On 2015-04-02 22:57-0700 Greg Jung wrote:
>
>>
>> In each setup there are naturally missing pieces.
>>>
>>> From my perspective,I need only libplplot.dll, libplplotcxx.dll,
>>
>> wingcc, svg, ps, null, Z, X, and maybe cairo devices, and wxwidget. If
>> a failure occurs because it isn't within this narrow requirement, that
>> is irrelevant.
>
>
> Hi Greg:
>
> But if the failure causes premature stopping of the test, then you
> don't have a complete test coverage for the components that are
> relevant to your needs.  So by all means for now explicitly drop all
> components that you don't want to comprehensively test (e.g., by using
> appropriate -DENABLE_???=OFF and -DPLD_???=OFF options via the
> --cmake_added_options option of scripts/comprehensive_test.sh) to
> allow you to complete the tests for a narrow set of components. Once
> such a limited test completes without failures, then we can note that
> success on our wiki and use it (if you are willing to make that exact
> same test again) as a benchmark for tests near the end of future
> release cycles to insure there are no regressions in the part of
> PLplot that interests you.
>
>> I should note that, in running the raw cmake without mod and without
>> setting variables,
>> I am wholly reliant on the pkgconfig system to find libraries and
>> sniff dependencies, which directs
>> cmake to look in the tree beneath the compiler distribution.
>
>
> Actually, CMake finds software using so-called find modules.  A few
> of those use pkg-config, but many do not.
>
>> in that respect the plplot build is a raging success.
>
>
> I agree that CMake is very good about finding software using whatever
> methods are used in the appropriate find module.  However, when you
> have multiple versions of the same software installed or if some of
> your installed software is installed in a non-standard location, you
> do have to direct CMake to find the correct software version that is
> appropriate for a particular platform by (typically) setting the
> environment variables PATH, CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH,
> and PKG_CONFIG_PATH.
>
>> If CMAKE were to find a library in /usr/lib this would be an error,
>> because that, analogous to the CYGWIN /usr/lib, is for programs to be
>> run under the msys- dll.
>
>
> Well, the user must set environment variables appropriate to each
> tested platform to give hints to CMake about finding software, and if
> they fail to set up a platform properly that way, it is a user error.
>
>> Compiling for Mingw using "MSYS Makefiles"
>> is really, from CMAKE point of view, a happy accident.  In that first
>> run the generator string turned out to be "Unix Makefiles" which
>> seemed to work nevertheless, in the make phase.  I re-ran mingw64 and
>> specified "MSYS Makefiles" for the same result.
>
>
> Not quite sure what you mean here because first you refer to Mingw,
> then to mingw64.  I suspect in both cases you meant MinGW-w64/MSYS2
> rather than MinGW/MSYS, but I am not completely sure.  Neverthess, I
> strongly agree with the principle that the generator you should use is
> dependent on platform.  For classical MinGW with no MSYS it is "MinGW
> Makefiles" (and you must also specify --build_command mingw32-make).
> For classicial MinGW/MSYS it is "MSYS Makefiles".  For Cygwin it is
> "Unix Makefiles".  My _guess_ for MinGW-w64/MSYS2 is that it should be
> "Unix Makefiles", (since that platform is a light-weight variant of
> modern Cygwin), but the exact generator to use is something you will
> have to discover for yourself since you are the first (that I am aware
> of) that has tried comprehensive testing on that particular platform.
>
>> My mingw tests didn't result in an install_tree/ so I suspect "make
>> install" is not an included step
>> in the script.  This is consistent with the ctest failure not picking
>> up ps driver etc.  I keep my usual
>> plplot drivers in a directory not on the MSYS path.
>>  All of the .dll files are there in the build directory but there is
>> no install directory.
>> ctest -j4 fails - if I manually go (cwd) to the build directory and "ctest
>> >& "
>> and get a series of the following messages:
>> 1: Testing front-end c
>> 1: x00c
>> 1: Unable to load driver: ps.
>> 1:
>> 1: *** PLPLOT ERROR, IMMEDIATE EXIT ***
>> 1: Unable to load driver
>> so either ps.info isn't being found, or ps.dll, or both.  If it is
>> working for you, perhaps you are finding these in the old
>> installation.
>
>
>> greg@Homerw7 MINGW64 /d/bld/plplot-mingw32/output_tree
>> $ ls -la
>> total 420
>> drwxr-xr-x 1 greg None      0 Apr  2 21:21 .
>> drwxr-xr-x 1 greg None      0 Mar 28 16:15 ..
>> -rw-r--r-- 1 greg None  19804 Mar 28 16:15 cmake.out
>> -rw-r--r-- 1 greg None   5568 Mar 28 17:06 ctest.out
>> -rw-r--r-- 1 greg None 397277 Mar 28 16:16 make.out
>> $ ls -la ../build_tree/dll
>> total 2744
>> drwxr-xr-x 1 greg None      0 Mar 28 16:16 .
>> drwxr-xr-x 1 greg None      0 Mar 30 08:31 ..
>> -rwxr-xr-x 1 greg None 143271 Mar 28 16:16 cairo.dll
>> -rwxr-xr-x 1 greg None 118558 Mar 28 16:15 libcsirocsa.dll
>> -rw-r--r-- 1 greg None   6542 Mar 28 16:15 libcsirocsa.dll.a
>> -rwxr-xr-x 1 greg None 509403 Mar 28 16:16 libplplot.dll
>> -rw-r--r-- 1 greg None 194548 Mar 28 16:16 libplplot.dll.a
>> -rwxr-xr-x 1 greg None 190112 Mar 28 16:16 libplplotcxx.dll
>> -rw-r--r-- 1 greg None 171696 Mar 28 16:16 libplplotcxx.dll.a
>> -rwxr-xr-x 1 greg None 278549 Mar 28 16:16 libplplottcltk.dll
>> -rw-r--r-- 1 greg None   3950 Mar 28 16:16 libplplottcltk.dll.a
>> -rwxr-xr-x 1 greg None  92430 Mar 28 16:16 libplplottcltk_Main.dll
>> -rw-r--r-- 1 greg None   1502 Mar 28 16:16 libplplottcltk_Main.dll.a
>> -rwxr-xr-x 1 greg None 120392 Mar 28 16:15 libqsastime.dll
>> -rw-r--r-- 1 greg None   3874 Mar 28 16:15 libqsastime.dll.a
>> -rwxr-xr-x 1 greg None  96826 Mar 28 16:15 libtclmatrix.dll
>> -rw-r--r-- 1 greg None   2782 Mar 28 16:15 libtclmatrix.dll.a
>> -rwxr-xr-x 1 greg None  90308 Mar 28 16:16 mem.dll
>> -rwxr-xr-x 1 greg None  95259 Mar 28 16:16 ntk.dll
>> -rwxr-xr-x 1 greg None  82507 Mar 28 16:16 null.dll
>> -rwxr-xr-x 1 greg None 120304 Mar 28 16:16 ps.dll
>> -rwxr-xr-x 1 greg None 108182 Mar 28 16:16 svg.dll
>> -rwxr-xr-x 1 greg None 106513 Mar 28 16:16 test-drv-info.exe
>> -rwxr-xr-x 1 greg None 107419 Mar 28 16:16 wingcc.dll
>> -rwxr-xr-x 1 greg None 100481 Mar 28 16:16 xfig.dll
>
>
> From those results, the ps device driver has been built, but ctest
> is not finding it at run-time.  I suspect the problem is you
> have not put the dll subdirectory on your PATH (which the
> comprehensive_testing.sh script does automatically for you).
>
>> Here now is a re-run of the mingw64 test, under msys2 using "MSYS
>> Makefiles"
>
>
>> $ ./comprehensive_test.sh --prefix /d/bld/plplot-mingw64-2
>> --generator_string 'MSYS Makefiles' --build_command 'make -j6'
>> --cmake_command '/d/programs/CMake-3.1.1-win32-x86/bin/CMake'
>> Summary of options used for these tests
>>
>> prefix=/d/bld/plplot-mingw64-2
>>
>> do_clean_as_you_go=yes
>>
>> generator_string=MSYS Makefiles
>>
>> ctest_command=ctest -j4
>> build_command=make -j6
>> cmake_command=/d/programs/CMake-3.1.1-win32-x86/bin/CMake
>
>
> Out of curiosity is that a generic Windows version of CMake or a
> special version that is installed by MinGW-w64/MSYS2?  It is possible
> (like has historically been true for Cygwin) that you need to use the
> MinGW-w64/MSYS2 version here.  Anyhow, using that version cannot
> hurt so I recommend you do so until you at least get a test success.
>
>> ....
>
>
> Please don't elide anything from the output of
> scripts/comprehensive_test.sh.  Furthermore, as I said before, I would
> far prefer you send that complete output for each of your platform
> reports as a (compressed) e-mail attachment.
>
>> Each of the steps in this comprehensive test may take a while....
>> Prepend /d/bld/plplot-mingw64-2/shared/build_tree/dll to the original PATH
>> /d/programs/CMake-3.1.1-win32-x86/bin/CMake in the build tree
>> make -j6 VERBOSE=1 in the build tree
>> ctest -j4 in the build tree
>>
>> $ ps
>>      PID    PPID    PGID     WINPID   TTY     UID    STIME COMMAND
>>     5328    5320    5008       3520  pty0    197609 21:49:04 /usr/bin/bash
>>     5516       1    5008       2980  pty0    197609 21:49:04 /usr/bin/bash
>>     1016    5516    5008       2736  pty0    197609 21:49:04 /usr/bin/bash
>>     3068    4076    5008       5468  pty0    197609 21:49:04 /usr/bin/bash
>>     4680       1    4680       4680  ?       197609 21:41:16
>> /usr/bin/mintty
>>     2744    5008    5008       5752  pty0    197609 21:49:04
>> /usr/local/bin/ctest
>>     4340    4032    4340        452  pty1    197609 22:01:00 /usr/bin/bash
>>     5428    4340    5428       5544  pty1    197609 22:01:05 /usr/bin/ps
>>     4076       1    5008       4388  pty0    197609 21:49:04 /usr/bin/bash
>>     4136    3068    5008       3084  pty0    197609 21:49:04
>> /d/bld/plplot-mingw64-2/shared/build_tree/examples/f95/x16af
>>     4160    1016    5008       3628  pty0    197609 21:49:04
>> /d/bld/plplot-mingw64-2/shared/build_tree/examples/c/x00c
>>     5008    1284    5008       1180  pty0    197609 21:47:23 /usr/bin/bash
>>     4916    5328    5008       3664  pty0    197609 21:49:04
>> /d/bld/plplot-mingw64-2/shared/build_tree/examples/c++/x00
>>     5320       1    5008       3632  pty0    197609 21:49:04 /usr/bin/bash
>>     3188       1    3188       3188  ?       197609 21:49:05 /usr/bin/bash
>>     1284    4680    1284       5856  pty0    197609 21:41:16 /usr/bin/bash
>>     4032       1    4032       4032  ?       197609 22:01:00
>> /usr/bin/mintty
>> This is where ctest is stuck.
>
>
>>
>> greg@Homerw7 MSYS /d/bld
>> $ ls -la plplot-mingw64-2/shared/build_tree/dll
>> total 4216
>> drwxr-xr-x 1 greg None      0 Apr  2 21:49 .
>> drwxr-xr-x 1 greg None      0 Apr  2 21:48 ..
>> -rwxr-xr-x 1 greg None 170985 Apr  2 21:48 cairo.dll
>> -rwxr-xr-x 1 greg None 152758 Apr  2 21:48 libcsirocsa.dll
>> -rw-r--r-- 1 greg None   6392 Apr  2 21:48 libcsirocsa.dll.a
>> -rw-r--r-- 1 greg None   1980 Apr  2 21:48 libplf95demolib.a
>> -rwxr-xr-x 1 greg None 534694 Apr  2 21:48 libplplot.dll
>> -rw-r--r-- 1 greg None 188940 Apr  2 21:48 libplplot.dll.a
>> -rwxr-xr-x 1 greg None 217046 Apr  2 21:48 libplplotcxx.dll
>> -rw-r--r-- 1 greg None 168438 Apr  2 21:48 libplplotcxx.dll.a
>> -rwxr-xr-x 1 greg None 214126 Apr  2 21:48 libplplotf95.dll
>> -rw-r--r-- 1 greg None  81022 Apr  2 21:48 libplplotf95.dll.a
>> -rwxr-xr-x 1 greg None 172797 Apr  2 21:48 libplplotf95c.dll
>> -rw-r--r-- 1 greg None 121598 Apr  2 21:48 libplplotf95c.dll.a
>> -rwxr-xr-x 1 greg None 282783 Apr  2 21:48 libplplottcltk.dll
>> -rw-r--r-- 1 greg None   3874 Apr  2 21:48 libplplottcltk.dll.a
>> -rwxr-xr-x 1 greg None 118072 Apr  2 21:48 libplplottcltk_Main.dll
>> -rw-r--r-- 1 greg None   1488 Apr  2 21:48 libplplottcltk_Main.dll.a
>> -rwxr-xr-x 1 greg None 117124 Apr  2 21:48 libplplotwxwidgets.dll
>> -rw-r--r-- 1 greg None  12730 Apr  2 21:48 libplplotwxwidgets.dll.a
>> -rwxr-xr-x 1 greg None 155495 Apr  2 21:48 libqsastime.dll
>> -rw-r--r-- 1 greg None   3788 Apr  2 21:48 libqsastime.dll.a
>> -rwxr-xr-x 1 greg None 122929 Apr  2 21:48 libtclmatrix.dll
>> -rw-r--r-- 1 greg None   2744 Apr  2 21:48 libtclmatrix.dll.a
>> -rwxr-xr-x 1 greg None 117760 Apr  2 21:48 mem.dll
>> -rwxr-xr-x 1 greg None 122153 Apr  2 21:48 ntk.dll
>> -rwxr-xr-x 1 greg None 109311 Apr  2 21:48 null.dll
>> -rwxr-xr-x 1 greg None 148115 Apr  2 21:48 ps.dll
>> -rwxr-xr-x 1 greg None 135523 Apr  2 21:48 svg.dll
>> -rwxr-xr-x 1 greg None 130767 Apr  2 21:48 test-drv-info.exe
>> -rwxr-xr-x 1 greg None 132902 Apr  2 21:48 wingcc.dll
>> -rwxr-xr-x 1 greg None 362512 Apr  2 21:49 wxwidgets.dll
>> -rwxr-xr-x 1 greg None 128448 Apr  2 21:48 xfig.dll
>
>
> I had a careful look at cmake.out, and I don't see any important
> issues there at all.  Furthermore, make.out is essentially perfectly
> clean, and your above results for the dll subdirectory look complete.
> So from that point of view it appears "MinGW MSYS" builds everything
> required for this MinGW-w64/MSYS2 case.  So these build tests appear to be
> quite promising, but the further run-time tests you do are failing.
>
> For example, if you look at ctest.out there is an obvious issue with one
> of the Tcl tests and it appears the whole ctest process is hung.
>
> So from our point of view, I will look post-release for the reason that
> Tcl error was not propagated properly to comprehensive_test.sh so that
> you got an explicit error result for that script.
>
> Otherwise, I am not sure whether that one failure in ctest is
> affecting (even perhaps hanging) the rest of the tests done by ctest
> so could you (1) try again with Tcl and Tk disabled?  If that result
> does not succeed, and tests are launched but never completed (i.e.,
> the whole process hangs even with Tcl and friends disabled), then my
> guess would be these run-time failures are due to incorrect cmake
> version or incorrect generator, so I suggest you should (2) do the
> same test again (i.e., with Tcl and friends disabled) with the cmake
> version that you can install on the MinGW-w64/MSYS2 platform.  And if
> that also hangs, then I suggest you (3) do the same test (with Tcl and
> friends disabled and using the cmake version installed on the
> MinGW-w64/MSYS2 platform) for the "Unix Makefiles" generator.
>
> Thanks in advance for taking the time to do these suggested further
> experiments for this new (for us) platform.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

[Plplot-devel] Release status: call for comprehensive testing: wxwidgets

[Alan W. I. <ir...@be...>]

I have just finished (once again) a complete test of wxwidgets for all
our standard examples.  I have reported the results (which are quite
encouraging) at the (re-edited)
https://sourceforge.net/p/plplot/bugs/151/.  It's this bug
report I will refer to in the release notes.

Freeze and release process continues....

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________