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...@beluga.phys.uvic.ca> 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 > __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
