On 2015-04-20 21:18-0700 Greg Jung wrote: > Alan, > Since these strings that are kept in files, that need to be > associated with each possible driver, > do not change over the years, why maintain a separate location? Why > not just compile those strings > into the body of plplot.obj? The increase of data size will probably > be balanced by the decrease in support code.
Hi Greg: Those <driver>.driver_info files are not static. They are configured instead (actually in two different ways that are compared against each other to check for internal consistency) depending on choices made by the user and resources available on the platform. I guess it should be possible to configure source code with these data, but I am pretty sure that would be an attempt to replace one configuration complexity with another so I don't think that effort would be worth the trouble. Note I am pretty sure Arjen's current MinGW/MSYS issues (and probably yours also when you tried to comprehensively test that platform) were due to a failure (for recent versions of classical MinGW/MSYS) to detect that the examples were being run in the build tree as opposed to the install tree. So the PLplot library that was built in the build tree was looking in the wrong install-tree locations for build-tree data (which doesn't work too well if nothing is installed yet). So this bug generated a lot of different testing issues of which finding the build-tree version of the <driver>.driver_info files was just one. And assuming I have fixed the "detection-of-build-tree test" bug, then my hope is most/all of those nagging Windows issues with finding resources that PLplot needs will just smoothly disappear. Note as soon as Arjen reports comprehensive testing success with MinGW/MSYS without having to take brute-force measures like setting PLPLOT* environment variables to get around the above "detection-of-build-tree test" bug, then I would encourage you to try comprehensive testing again on that platform (as well as MinGW-w64/MSYS2) using a tailored version of the "comprehensively test, and collect" script that will be included with his test report tarball. 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 __________________________ ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel