Re: [Plplot-devel] convenient windows developing

[Alan W. I. <ir...@be...>]

On 2006-11-27 12:12+0100 Werner Smekal wrote:

> Hi,
>
>>
>> I'm unhappy about requiring python (or anything else non-standard) for
>> running the tests. This adds another significant dependency to the build
>> process. We're already asking users to install a fair bit. I guess this
>> is particularly an issue for windows users.
>
> Yes, windows user need to spend quite a time to have everything setup.
> That's the reason why I thought we should provide a binary package for
> Windows with libraries for MinGW and Visual C++ 6.0 (which can be used
> for all other Visual C++ as well, I think). Together with the headers
> and data files. This is actually all you need for c/c++ development on
> Windows.
>
> Apart from that, it may be the smartest than to write Windows batch
> files or jim/tcl files. From the jim website I think it should be no
> problem that jim compiles on most compilers - I'll write a cmake file
> and test it on various Windows compilers.

Hmm... It's interesting how my comment about a parallel windows scripting
system for ctest has sparked so much interest. A consensus seems to have
formed for building jim/tcl as part of PLplot and making jim scripts with
the same functionality as plplot-test.sh and the various test*.sh scripts,
but I have two reservations about this solution.

1) It adds parallel maintenance that Werner and Arjen have to apply to
the jim scripts any time there is a change to plplot-test.sh and the
other test*.sh scripts.  This is all fairly trivial stuff (adding new
examples, finding better ways to configure the tests), but there is a fair
amount of churn, and it will be irritating to keep the two systems in sync.

2) There is also a maintenance burden for jim itself.  Werner and Arjen have
to keep track of new jim releases, make judgement calls about the stability of
those releases, and decide when to deploy them into the PLplot code base.

The first of these reservations also applies to all other parallel scripting
systems (with python, perl, or whatever) which is why my opinion _now_ is we
should reject all of them.  I only brought up the idea of parallel scripts
originally because I was under the impression no bash solutions were
available for windows, but it appears that such solutions exist.  In fact,
Werner was able to get all but the java ctests passed with the windows bash
solution he found, and I doubt a solution is far away in that case.

It appears the only downside to the windows bash solution is our windows
developers and users will need to independently install bash if they want to
use ctest and/or the install-tree plplot-test.sh tests.  I doubt installing
a windows bash is going to be a difficult burden for Arjen or any other
windows developer that wants to contribute to PLplot since Werner has
already been successful at this, and almost by definition our developers are
good at installing PLplot dependencies.  That leaves only the question of
our users. To make life easier for them, I think we should put together a
test to look for bash.  If that test fails we should give the appropriate
warning message, force BUILD_TEST to OFF, and not configure or install
plplot-test.sh and the test*.sh scripts.  Also, Werner should expand our
wiki a bit more giving a reference to windows bash and perhaps a sentence or
two about how to install it if that is not obvious.

With those changes it should be straightforward for our windows users to
install bash, but if they choose not to do so, all that will happen is they
will receive a CMake warning and the ctest functionality will be missing and
install tree tests not available. So it will be exactly like any other
component of PLplot. If you want a particular PLplot component you have to
pay the price of installing the relevant software.

In sum, I have given my reasons why I prefer a uniform bash solution for all
platforms (especially since it apparently already works on bare windows
except for one minor Java issue).  However, if the windows developers still
prefer the jim/tcl alternative (and are willing to develop it and more
importantly maintain it), I will go along since windows developers know
a lot more about windows than I do. :-)

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________