On 2014-05-25 10:41-0000 Arjen Markus wrote: > Hi Alan, > >> There is still one issue, however, in the results you report. You state for >> the build-tree case that the drivers are being loaded from the install tree. >> Are you sure? Because there is nothing in the above messages that confirms >> or denies that and that result is obviously not the desired one (where the >> build-tree version of the drivers should be used for the build-tree case). > > I formulated this imprecisely. The situation is this: > > 1. Run the example from within the build tree, with the PATH referring to the > build-tree's dll subdirectory: > - the drivers come from that dll subdirectory > - the data files (.pal, .fnt, ...) come from the source tree's data > subdirectory > > 2. Run the example from within the build tree, but the PATH referring to the > installation's dll subdirectory: > - the drivers come from the installation's dll subdirectory > - the data files come from the source (!) tree's data subdirectory > > 3. Copy the example program to a completely independent directory (d:/tmp in > my case), and run it with the > PATH referring to the installation's dll subdirectory - the situation if > someone has installed Plplot and built > a program of his/her own: > - the drivers come from the installation's dll subdirectory > - the data files come from the installation's (!) data subdirectory >
Hi Arjen: Thanks for those results (including 2) which are exactly as expected. Just to explain what is going on, the PLplot library is identical for the build-tree and install-tree cases so you cannot rely on some macro defined in the build-tree variant that is not also defined in the install-tree library since essentially they are the same library. Thus, instead a run-time test needs to be done (implemented in the plInBuildTree function) to decide whether the current directory is within the build tree or not. For both Unix and Windows (and Cygwin) plInBuildTree is called during the process of finding data files so that explains the data file results for 2 since you are in the build tree for that case. The location of the device drivers is handled in a completely separate manner. For the Unix case plInBuildTree is called to decide whether to prepend the build-tree or install-tree path to the device driver name so you end up with expected results for the location of drivers and data files regardless of PATH. The Windows (including Cygwin) case is handled quite differently. There, no directory is prepended to the device driver name and instead the PATH is used to decide the location of the device driver. So if you choose a PATH that is inconsistent with your location in the build tree (case 2 above) you get exactly the inconsistent result you described. So in the Windows case the code is executing exactly as designed, but if you are concerned about the possible inconsistency that can result if you use the wrong PATH as in case 2 above, then you could redesign the Windows (including Cygwin) implementation so that it also prepended the correct build-tree or install-tree path to the device driver name. I would think such an implementation would be straightforward for you to do if you felt it was a priority, but it would require build-tree and install-tree testing for the Cygwin, pure MinGW, MinGW/MSYS, and MSVC cases to make sure that implementation was correct. (I separate the pure MinGW and MinGW/MSYS cases because the paths are treated differently in those two cases.) Finally, for the present PATH method I have good pure MinGW results and you have good Cygwin results, but when convenient (i.e. whenever we are doing other tests on the indicated platform) we should both probably extend that testing (tests 1 and 3 above) to all other Windows platforms accessible to us (MinGW/MSYS in my case and pure MinGW, MinGW/MSYS, and MSVC in your 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 __________________________ ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
