On 2014-10-15 10:28-0000 Arjen Markus wrote: > Hi everyone, > > I am trying to test the build under MinGW/MSYS, but I have run into a problem > with the device drivers: > The example programs can not find them, unless I set PLPLOT_DRV_DIR to the > directory containing the .driver_info files.
> However, when I set that environment variable [to work around the issue above], the examples abort immediately, as they can not find the .pal or .fnt files. > I thought it might have to do with the plInBuildTree() function: I run the programs from within the build tree, but MSYS uses the forward slash to indicate directory segments whereas Windows and the code for plInBuildTree() uses the backslash. Hi Arjen: Your present results are not consistent with the complete comprehensive testing success with MinGW/MSYS I got back in March of this year (using CMake-2.8.12.1 as documented at http://sourceforge.net/p/plplot/wiki/Testing_PLplot/). Also, they are not consistent with your own previous good testing results for MinGW/MSYS. So the question is what has introduced this regression? Is it a regression in CMake between 2.8.12.x and 3.0.x (assuming you are using the latter for these tests), a regression in our build system since March, or a regression in how you are doing the testing compared to the way you did testing in the past and the way I did my testing back in March. To help figure that out (and also because my own MinGW/MSYS/Wine testing platform is 20 times slower than normal so I cannot afford to make comprehensive tests very often) let's simplify the test to the following (IMPORTANT for CMake-2.8.12.2 with the test done in the build tree for the default shared library build and dynamic devices build): PATH=<build_tree_location>/dll:$PATH make all examples/c/x01c -dev psc -o test.psc I will also run that simple test here for my MinGW/MSYS/Wine platform (this time for both CMake-2.8.12.2 and CMake-3.0.2), and if I discover any build-system issues introduced since March I will fix those, and if I demonstrate any CMake regressions, I will try to deal with those as well so that CMake-3.0.2 produces the same simple test results as CMake-2.8.12.2. But I may see no problems at all for either case which is why it is important to see whether the above simple test works for you as well. > I will now move on to testing the build under MinGW. I prefer not to be distracted by the MinGW platform case until we solve this MinGW/MSYS platform regression since once this regression is resolved the fix will likely affect all Windows platforms (regardless of the three possible kinds of regression it could be). More later on the results of the above simple test for MinGW/MSYS/Wine. 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 __________________________ ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
