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

Reply via email to