I would not do anything that was driven by
being usable by the Fortran Tools. That just
does not cover enough of your potential users.

Having said that, I would think that anything
that builds and runs in a Mingw-only
environment should work. I don't think I have
had any problem incorporating into the FT
any binary distribution that is built for
Windows.

Alan: do you really want to look at the results
of my build attempts? It seems quite obvious that
there is something "wrong" with my system
configuration or the way I am trying to do things.


On Sun, May 4, 2014 at 8:57 AM, Arjen Markus <Arjen.Markus@deltares.nl> wrote:

HI Walt,

 

This has been on our nice-to-have list for quite some time. The real problem is that there are many configurations to worry about:

-        Which languages and compilers to support? And which versions?

-        Which external components to support?

 

Since we switched to CMake as the configuration tool, things have become easier to build and CMake comes with a simple packaging option, so that ought to make a binary distribution easier as well, though the above still holds.

 

If we limit ourselves to the context of FortranTools, the number of configurations may get down to something manageable.  Do you have suggestions?

 

Regards,

 

Arjen

 

From: Walt Brainerd [mailto:walt.brainerd@gmail.com]
Sent: Friday, May 02, 2014 6:38 PM
To: Alan W. Irwin
Cc: plplot_general


Subject: Re: [Plplot-general] Including cairo driver

 

Thanks for all of that explanation.

 

At some point I will try to build pango/cairo and Qt5

from scratch using Mingw only. But obviously I am

not as good at this kind of thing as you guys.

 

Maybe something to think about for the future if you

can get somebody with MS Windows experience to

do it--provide a Windows binary package. Most of the

things I use come that way (Mingw, GTK, Code::Blocks,

etc.) That makes it a whole lot easier for people like

me who are not so good at building things from scratch.

 

Anyway, thanks again.

 

 

 

On Thu, May 1, 2014 at 8:19 PM, Alan W. Irwin <irwin@beluga.phys.uvic.ca> wrote:

Hi Walt:

On 2014-05-01 17:06-0700 Walt Brainerd wrote:

> I lied. I didn't completely give up and have made some
> progress.
>
> I completely disabled cygwin and went back to the command
> and version of cmake that Darius suggested with Mingw files.
>
> This is OK because the Fortran Tools do not include cygwin
> (just mingw) so the compilations can be consistent. I think all
> the problems have been caused by multiple versions of libraries
> and incorrect paths, but who knows ...

I think that is an extremely likely explanation.  But if you are
careful (in the way I stated previously to you) to set environment
variables so that for MinGW you stick completely to MinGW dependencies
and for Cygwin you stick completely to Cygwin dependencies, you should
be able to build PLplot under both Cygwin and MinGW on one box.

> I still can't get cairo, but that is OK.

The PLplot dependencies on external libraries are currently a big
issue for MinGW.  To get pretty close to what you have on Cygwin, you
would need at least binary versions of Qt5 and the pango/cairo subset
of the GTK+ stack of libraries which are needed by our "qt" and cairo
device drivers.  Those are our two best such device drivers and they
implement a substantial number of devices between them including those
which implement the PNG, JPEG, and PDF formats as well as many other
formats. If you download binary versions of Qt5 and pango/cairo it is
unlikely that either/both are going to be ABI consistent with the
single MinGW version you use to build PLplot.  So really the only good
choice is to build the external libraries yourself with exactly the
same MinGW version you use to build PLplot.  That should be
straightforward to do because those external libraries are all
open-source with well-defined procedures for building with MinGW on
Windows.  But it is not an easy task because the Windows build lore
that is required for each different piece of software is often hard to
dig out of the google noise.  I am working to fix that situation with
the epa_build idea (see below), but for now those who use MinGW
normally settle for an extremely light-weight version of PLplot
without the cairo, qt, and wxwidgets device drivers which means
essentially only the ps, svg, and wingcc devices are available for
MinGW.

> The examples x??f.f90 work
> and I was able to provide all the files needed to relocate (necessary
> to distribute). So I am pretty happy. And plan to include plplot in
> the next version of the Fortran Tools. I need to write up a little
> section explaining it with a couple of simple examples, just like
> I have done with the other tools (fortran.com/Fortran_Tools.pdf).
>
> One last attempt: can any of you point me to how to build things
> so that I can generate a jpeg, tif, png, etc. file? This would be a
> nice feature to include. I can produce a .svg file that can be
> inserted as a picture into an Open Office document and I can
> generate with wingcc on the screen and incorporate the plot
> into Word as a screen shot, so those are two ways to keep the
> plotting results that I know how to do.

See explanation above about why the MinGW version of PLplot is so
limited for now.  I do have a subproject of PLplot called epa_build
(see cmake/epa_build/README) which allows you to conveniently build
all PLplot dependencies (other than octave which I have not epa_build
configured yet) on Unix.  And all aspects of the epa_build approach
should eventually work on MinGW as well.  In fact, every external
library package that epa_builds on Unix also epa_builds on MinGW
except for Qt5 and the pango/cairo subset of GTK+. Digging out the
Windows lore on how to build those packages takes some effort as well
as a lot of build experimentation, and, in fact, I cannot do that
build experimentation myself because I don't have access to Microsoft
Windows. So I am currently looking for someone who does have such
access who is willing to do the work (with backup help from me) to get
Qt5 and pango/cairo epa_build to MinGW.  That is a really important
project from the PLplot prospective since it will transform MinGW from
a light-weight PLplot platform to a powerful PLplot platform.

Meanwhile, Cygwin already has all the PLplot dependencies available in
an ABI consistent way.  And Arjen has run with this possibility and
demonstrated that essentially all PLplot functionality works on
Cygwin.  So that powerful PLplot platform is the one I recommend to
our Windows users for now if they need more than just PostScript or
SVG results.

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-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general



 

--
Walt Brainerd

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.



--
Walt Brainerd