plplot-general — PLplot user discussion group

Re: [Plplot-general] Compiling against the Fortran77 libraries in PLPlot 5.10.0

[David V. <dve...@gm...>]

Thanks, Arjen.


On Sun, May 18, 2014 at 11:49 PM, Arjen Markus <Arj...@de...>wrote:

>  Hi David,
>
>
>
> I do not know how the libraries are distributed in Ubuntu, but if only the
> shared versions are distributed, that will be a very deliberate choice of
> the distributors. Even though the shared libraries get exercised more, you
> should be able to build them yourself.
>
>
>
> As for the difference between the F77 and F95 bindings:
>
> -        First of all, inserting a “use plplot” statement will allow the
> compiler to “see” the interface definitions.
>
> -        This is necessary for it to insert the right internal names of
> the routines (otherwise the linker will complain)
>
> -        But more importantly, the compiler will be able to check the
> argument lists of the routines. Arguments that have changed between F77 and
> F95 are things like the number of elements in an array. In F95
> introspection is possible and that avoids many mistakes. It does mean some
> incompatibility unfortunately.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
> *From:* David Ventimiglia [mailto:dve...@gm...]
> *Sent:* Sunday, May 18, 2014 1:55 PM
> *To:* Moez Kilani
> *Cc:* plplot_general
> *Subject:* Re: [Plplot-general] Compiling against the Fortran77 libraries
> in PLPlot 5.10.0
>
>
>
> Thanks, Alan and Moez.
>
>
>
> On Sat, May 17, 2014 at 10:27 PM, Moez Kilani <moe...@gm...>
> wrote:
>
> Hi David,
>
> I also liked the fortran77 bindings. For the F95 bindings, I have posted
> an example on my web page :
>
> http://perso.univ-lille3.fr/~mkilani/other/other.html
>
> hope it helps (notice lines 2, 42-51) !
>
> Best
>
>
>
> 2014-05-18 3:44 GMT+02:00 David Ventimiglia <dve...@gm...>:
>
> Hi,
>
>
>
> How do I compile Fortran77 programs against PLPlot now that the Fortran77
> libraries have finally been removed from libplplot-dev (I'm on Ubuntu, so
> this is a Debian style package)?  On my system I also see that there now is
> a libplplot-fortran11 package whose description says:
>
>
>
> This package contains the Fortran 77 and Fortran 95 bindings for
> PLplot. Note: the Fortran 77 bindings have been deprecated in the latest
> version of PLplot, and will be dropped from a future release. New code
> should use the Fortran 95 bindings.
>
>
>
> But, within it there are only shared-object libraries and no longer any
> static libraries, which were very convenient.  Further, where are the
> actually Fortran77 libraries?  The .so files here all are labelled with
> f95, and they seem to contain Fortran95 style symbols and don't contain
> Fortran77 symbols.  Have the Fortran77 libraries actually been completely
> purged?
>
>
>
> Thanks!
>
> Best,
>
> David
>
>
>
>
> ------------------------------------------------------------------------------
> "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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>
>
>
>
>  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.
>

Re: [Plplot-general] Compiling against the Fortran77 libraries in PLPlot 5.10.0

[Andrew R. <and...@us...>]

For Debian / Ubuntu we only build the shared libraries. The packages are 
somewhat out of date. Sorry - this is a combination of me not having much 
time to work on this, and also the fact that the latest version of plplot 
needs the newest version of cmake to work correctly with octave. I've been 
waiting on this to reach unstable so I can upload the new packages. The 
Debian packaging files are part of the plplot svn repository, but not 
distributed with the source so you can always try those if you fancy 
building your own packages!

Andrew

On Mon, May 19, 2014 at 06:49:21AM +0000, Arjen Markus wrote:
> Hi David,
> 
> I do not know how the libraries are distributed in Ubuntu, but if only the shared versions are distributed, that will be a very deliberate choice of the distributors. Even though the shared libraries get exercised more, you should be able to build them yourself.
> 
> As for the difference between the F77 and F95 bindings:
> 
> -        First of all, inserting a “use plplot” statement will allow the compiler to “see” the interface definitions.
> 
> -        This is necessary for it to insert the right internal names of the routines (otherwise the linker will complain)
> 
> -        But more importantly, the compiler will be able to check the argument lists of the routines. Arguments that have changed between F77 and F95 are things like the number of elements in an array. In F95 introspection is possible and that avoids many mistakes. It does mean some incompatibility unfortunately.
> 
> Regards,
> 
> Arjen
> 
> From: David Ventimiglia [mailto:dve...@gm...]
> Sent: Sunday, May 18, 2014 1:55 PM
> To: Moez Kilani
> Cc: plplot_general
> Subject: Re: [Plplot-general] Compiling against the Fortran77 libraries in PLPlot 5.10.0
> 
> Thanks, Alan and Moez.
> 
> On Sat, May 17, 2014 at 10:27 PM, Moez Kilani <moe...@gm...<mailto:moe...@gm...>> wrote:
> Hi David,
> 
> I also liked the fortran77 bindings. For the F95 bindings, I have posted an example on my web page :
> 
> http://perso.univ-lille3.fr/~mkilani/other/other.html
> 
> hope it helps (notice lines 2, 42-51) !
> 
> Best
> 
> 2014-05-18 3:44 GMT+02:00 David Ventimiglia <dve...@gm...<mailto:dve...@gm...>>:
> Hi,
> 
> How do I compile Fortran77 programs against PLPlot now that the Fortran77 libraries have finally been removed from libplplot-dev (I'm on Ubuntu, so this is a Debian style package)?  On my system I also see that there now is a libplplot-fortran11 package whose description says:
> 
> This package contains the Fortran 77 and Fortran 95 bindings for
> PLplot. Note: the Fortran 77 bindings have been deprecated in the latest
> version of PLplot, and will be dropped from a future release. New code
> should use the Fortran 95 bindings.
> 
> But, within it there are only shared-object libraries and no longer any static libraries, which were very convenient.  Further, where are the actually Fortran77 libraries?  The .so files here all are labelled with f95, and they seem to contain Fortran95 style symbols and don't contain Fortran77 symbols.  Have the Fortran77 libraries actually been completely purged?
> 
> Thanks!
> Best,
> David
> 
> ------------------------------------------------------------------------------
> "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
> Plp...@li...<mailto:Plp...@li...>
> https://lists.sourceforge.net/lists/listinfo/plplot-general
> 
> 
> 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.

> ------------------------------------------------------------------------------
> "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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] Compiling against the Fortran77 libraries in PLPlot 5.10.0

[Arjen M. <Arj...@de...>]

Hi David,

I do not know how the libraries are distributed in Ubuntu, but if only the shared versions are distributed, that will be a very deliberate choice of the distributors. Even though the shared libraries get exercised more, you should be able to build them yourself.

As for the difference between the F77 and F95 bindings:

-        First of all, inserting a “use plplot” statement will allow the compiler to “see” the interface definitions.

-        This is necessary for it to insert the right internal names of the routines (otherwise the linker will complain)

-        But more importantly, the compiler will be able to check the argument lists of the routines. Arguments that have changed between F77 and F95 are things like the number of elements in an array. In F95 introspection is possible and that avoids many mistakes. It does mean some incompatibility unfortunately.

Regards,

Arjen

From: David Ventimiglia [mailto:dve...@gm...]
Sent: Sunday, May 18, 2014 1:55 PM
To: Moez Kilani
Cc: plplot_general
Subject: Re: [Plplot-general] Compiling against the Fortran77 libraries in PLPlot 5.10.0

Thanks, Alan and Moez.

On Sat, May 17, 2014 at 10:27 PM, Moez Kilani <moe...@gm...<mailto:moe...@gm...>> wrote:
Hi David,

I also liked the fortran77 bindings. For the F95 bindings, I have posted an example on my web page :

http://perso.univ-lille3.fr/~mkilani/other/other.html

hope it helps (notice lines 2, 42-51) !

Best

2014-05-18 3:44 GMT+02:00 David Ventimiglia <dve...@gm...<mailto:dve...@gm...>>:
Hi,

How do I compile Fortran77 programs against PLPlot now that the Fortran77 libraries have finally been removed from libplplot-dev (I'm on Ubuntu, so this is a Debian style package)?  On my system I also see that there now is a libplplot-fortran11 package whose description says:

This package contains the Fortran 77 and Fortran 95 bindings for
PLplot. Note: the Fortran 77 bindings have been deprecated in the latest
version of PLplot, and will be dropped from a future release. New code
should use the Fortran 95 bindings.

But, within it there are only shared-object libraries and no longer any static libraries, which were very convenient.  Further, where are the actually Fortran77 libraries?  The .so files here all are labelled with f95, and they seem to contain Fortran95 style symbols and don't contain Fortran77 symbols.  Have the Fortran77 libraries actually been completely purged?

Thanks!
Best,
David

------------------------------------------------------------------------------
"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
Plp...@li...<mailto:Plp...@li...>
https://lists.sourceforge.net/lists/listinfo/plplot-general


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.

Re: [Plplot-general] Compiling against the Fortran77 libraries in PLPlot 5.10.0

[David V. <dve...@gm...>]

Thanks, Alan and Moez.


On Sat, May 17, 2014 at 10:27 PM, Moez Kilani <moe...@gm...> wrote:

> Hi David,
>
> I also liked the fortran77 bindings. For the F95 bindings, I have posted
> an example on my web page :
>
> http://perso.univ-lille3.fr/~mkilani/other/other.html
>
> hope it helps (notice lines 2, 42-51) !
>
> Best
>
>
> 2014-05-18 3:44 GMT+02:00 David Ventimiglia <dve...@gm...>:
>
>> Hi,
>>
>> How do I compile Fortran77 programs against PLPlot now that the Fortran77
>> libraries have finally been removed from libplplot-dev (I'm on Ubuntu, so
>> this is a Debian style package)?  On my system I also see that there now is
>> a libplplot-fortran11 package whose description says:
>>
>> This package contains the Fortran 77 and Fortran 95 bindings for
>>> PLplot. Note: the Fortran 77 bindings have been deprecated in the latest
>>> version of PLplot, and will be dropped from a future release. New code
>>> should use the Fortran 95 bindings.
>>
>>
>> But, within it there are only shared-object libraries and no longer any
>> static libraries, which were very convenient.  Further, where are the
>> actually Fortran77 libraries?  The .so files here all are labelled with
>> f95, and they seem to contain Fortran95 style symbols and don't contain
>> Fortran77 symbols.  Have the Fortran77 libraries actually been completely
>> purged?
>>
>> Thanks!
>> Best,
>> David
>>
>>
>> ------------------------------------------------------------------------------
>> "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
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-general
>>
>>
>

Re: [Plplot-general] Compiling against the Fortran77 libraries in PLPlot 5.10.0

[Moez K. <moe...@gm...>]

Hi David,

I also liked the fortran77 bindings. For the F95 bindings, I have posted an
example on my web page :

http://perso.univ-lille3.fr/~mkilani/other/other.html

hope it helps (notice lines 2, 42-51) !

Best


2014-05-18 3:44 GMT+02:00 David Ventimiglia <dve...@gm...>:

> Hi,
>
> How do I compile Fortran77 programs against PLPlot now that the Fortran77
> libraries have finally been removed from libplplot-dev (I'm on Ubuntu, so
> this is a Debian style package)?  On my system I also see that there now is
> a libplplot-fortran11 package whose description says:
>
> This package contains the Fortran 77 and Fortran 95 bindings for
>> PLplot. Note: the Fortran 77 bindings have been deprecated in the latest
>> version of PLplot, and will be dropped from a future release. New code
>> should use the Fortran 95 bindings.
>
>
> But, within it there are only shared-object libraries and no longer any
> static libraries, which were very convenient.  Further, where are the
> actually Fortran77 libraries?  The .so files here all are labelled with
> f95, and they seem to contain Fortran95 style symbols and don't contain
> Fortran77 symbols.  Have the Fortran77 libraries actually been completely
> purged?
>
> Thanks!
> Best,
> David
>
>
> ------------------------------------------------------------------------------
> "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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>
>

Re: [Plplot-general] Compiling against the Fortran77 libraries in PLPlot 5.10.0

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

On 2014-05-17 18:44-0700 David Ventimiglia wrote:

[out of order]
> On my system I also see that there now is
> a libplplot-fortran11 package whose description says:
>
> This package contains the Fortran 77 and Fortran 95 bindings for
>> PLplot. Note: the Fortran 77 bindings have been deprecated in the latest
>> version of PLplot, and will be dropped from a future release. New code
>> should use the Fortran 95 bindings.

That description is outdated by two releases.  Updating that is
the Debian/Ubuntu packager's responsibility.

> Have the Fortran77 libraries actually been completely
> purged?

Yes, actually for a prior release (5.9.11).

> How do I compile Fortran77 programs against PLPlot now that the Fortran77
> libraries have finally been removed from libplplot-dev (I'm on Ubuntu, so
> this is a Debian style package)?

I am pretty sure all you have to do is insert a "use plplot" statement
in your old fortran code, but others here may have a better answer.

> But, within it there are only shared-object libraries and no longer any
> static libraries, which were very convenient.

The question of packaging the static libraries is a Debian/Ubuntu
packaging question which I cannot answer.

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
__________________________

[Plplot-general] Compiling against the Fortran77 libraries in PLPlot 5.10.0

[David V. <dve...@gm...>]

Hi,

How do I compile Fortran77 programs against PLPlot now that the Fortran77
libraries have finally been removed from libplplot-dev (I'm on Ubuntu, so
this is a Debian style package)?  On my system I also see that there now is
a libplplot-fortran11 package whose description says:

This package contains the Fortran 77 and Fortran 95 bindings for
> PLplot. Note: the Fortran 77 bindings have been deprecated in the latest
> version of PLplot, and will be dropped from a future release. New code
> should use the Fortran 95 bindings.


But, within it there are only shared-object libraries and no longer any
static libraries, which were very convenient.  Further, where are the
actually Fortran77 libraries?  The .so files here all are labelled with
f95, and they seem to contain Fortran95 style symbols and don't contain
Fortran77 symbols.  Have the Fortran77 libraries actually been completely
purged?

Thanks!
Best,
David

Re: [Plplot-general] Including cairo driver

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

On 2014-05-15 12:58-0700 Walt Brainerd wrote:

> OK. I think I have it.
> Using your latest instructions, I get cairo and wingcc drivers.

Excellent.

> Lots of names changed by having to drop the "d" at the end.
> I assume I was doing a double precision build.

Yes.  By default the double-precision version of our library is the
one that is built.

And you are right we have now dropped the whole idea of a suffix to
the library name to describe some attribute (such as double precision)
of the build.  In my view, simpler (i.e, a fixed library name in this
case) is better.

>
> I nominate you for Amazing Remote Debugger. (Maybe I
> could do some of that with a Fortran program, but not this
> kind of stuff.)
>
> Thanks again for all the help.

You are welcome, and thanks for your persistence which inspired me to
look for the first time in many years at the combination of a binary
download of GTK+ and PLplot built with MinGW and finally get that
combination to work properly.

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
__________________________

Re: [Plplot-general] Including cairo driver

[Walt B. <wal...@gm...>]

OK. I think I have it.
Using your latest instructions, I get cairo and wingcc drivers.

I didn't do anything about -lm to get things to work ???
When it worked before, I had to delete -lintl ???

Lots of names changed by having to drop the "d" at the end.
I assume I was doing a double precision build.

I nominate you for Amazing Remote Debugger. (Maybe I
could do some of that with a Fortran program, but not this
kind of stuff.)

Thanks again for all the help. Plplot is going into the next
Fortran Tools, but I don't yet much info about using it with
cairo. I must suspend the fun stuff as I have a little job to
"modernize" 1,000,000 lines of Fortran code.

I still would welcome comments on that attempt to use
Plplot.


On Wed, May 14, 2014 at 8:24 PM, Alan W. Irwin <ir...@be...>wrote:

> On 2014-05-14 16:37-0700 Walt Brainerd wrote:
>
>  I seem to be going backwards.
>> I downloaded the trunk and executed cmake with
>> what I think is all of your requested options.
>>
>> I get neither cairo nor wingcc now. Don't know why I
>> keep getting the "not found" messages.
>>
>
> Hi Walt:
>
> Don't get discouraged.  You are actually moving forward.  :-)
>
> For example, I am pretty good at remote debugging (which we must
> necessarily do in this case since I do not confirm the issue you are
> finding on my own Windows platform, and I don't expect you to
> completely understand the PLplot build system logic at first glance).  I
> actually think we are pretty close to a solution, see below.
>
> I see nothing wrong with your cmake options.
>
> There was enough information in the cmake output so that I realized
> you are failing to find one particular library.  I am virtually
> positive that library (not only required for wingcc but also our cairo
> device driver on Windows) is gdi32, but the warning diagnositics
> provided by our build system are not currently detailed enough to
> confirm that. So I have (as of revision 13120) updated those
> diagnostics to be much more verbose when something is going wrong with
> pkg-config so the library that is not found can at least be figured
> out from those diagnostic messages.
>
> So for the next iteration do an svn update first to get access to the
> better warnings.  Also, if you are not following this good advice
> already, please delete your old build tree and start over with an
> empty build tree (so your build is not clobbered by bad stale results
> that are cached from your previous failing attempts).
>
> Note, I am pretty sure you will not have further trouble if you
> provide CMake the obvious guidance it needs to find the gdi32 library.
> Also, I must say that getting that guidance right was the most
> difficult aspect of my own MinGW/Wine test case. In my case with
> MinGW-4.7.2 the location of that library was in a subdirectory of the
> MinGW install, i.e., z:/home/wine/newstart/MinGW-4.7.2/lib/libgdi32.a.
> (and if I specified an alternative Windows system location that
> appeared to contain a dll related to gdi32, that did not work in the
> slightest with a run-time error message concerning a wrong library
> format.)
>
> So it was essential for me to set one component of the environment
> variable CMAKE_LIBRARY_PATH to z:/home/wine/newstart/MinGW-4.7.2/lib
> so that CMake would know to look in that directory for the gdi32
> library that our build system needs.  I am pretty sure setting the
> CMAKE_LIBRARY_PATH environment variable equivalently (using the
> appropriate install prefix for wherever you installed MinGW) will
> "just work" for you.
>
> However, if not, I am game for at least one more iteration of remote
> debugging if you continue to provide me with your cmake invocation,
> cmake output, _and_ also add the relevant environment variables (I
> have mentioned the complete list of those before in this thread) and the
> CMakeCache.txt file in the top of the build tree that is generated by
> the cmake command.  And if cmake is okay, but the further build is
> not, then you should supply the additional VERBOSE=1 output from
> that build.
>
>
>  and now I can't
>> even get pkg-config to work from the command.
>>
>> C:\walt\Software\Plplot\BUILD>dir C:\FortranTools\gtk\lib\
>> pkgconfig\cairo.pc
>> Volume in drive C has no label.
>> Volume Serial Number is BADA-0412
>>
>> Directory of C:\FortranTools\gtk\lib\pkgconfig
>>
>> 09/21/2013  06:46 AM               409 cairo.pc
>>               1 File(s)            409 bytes
>>               0 Dir(s)  35,996,807,168 bytes free
>>
>> C:\walt\Software\Plplot\BUILD>pkg-config cairo
>>
>
> That is not the correct way to get library and cflags information
> out of pkg-config.  Run
>
> pkg-config --help
>
> to see what is possible.  But to get all the library flags
> for the cairo library you should invoke it as
>
> pkg-config --libs cairo
>
> and similarly the compile flags are determined using
>
> pkg-config --cflags cairo
>
> So make sure those commands give you sensible looking results which
> tests that your PATH and possibly (if needed) your PKG_CONFIG_PATH
> environment variables are set up properly to find cairo.  Note, this
> is only a test and not part of the build since cmake calls pkg-config
> internally using the PATH and PKG_CONFIG_PATH environment variables
> you have set (and then transforms the results afterwards into the
> form that is needed including dropping -lm for the Windows case).
>
> Please see request above for all the information that is required
> including all relevant environment variables if you have any troubles
> for this iteration.  But I predict if there is a problem, then as soon
> as you collect the requested information for me, you will probably
> immediately understand and fix the problem with your setup.  :-)
>
>
> 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
> __________________________
>



-- 
Walt Brainerd

Re: [Plplot-general] Including cairo driver

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

On 2014-05-14 16:37-0700 Walt Brainerd wrote:

> I seem to be going backwards.
> I downloaded the trunk and executed cmake with
> what I think is all of your requested options.
>
> I get neither cairo nor wingcc now. Don't know why I
> keep getting the "not found" messages.

Hi Walt:

Don't get discouraged.  You are actually moving forward.  :-)

For example, I am pretty good at remote debugging (which we must
necessarily do in this case since I do not confirm the issue you are
finding on my own Windows platform, and I don't expect you to
completely understand the PLplot build system logic at first glance).  I
actually think we are pretty close to a solution, see below.

I see nothing wrong with your cmake options.

There was enough information in the cmake output so that I realized
you are failing to find one particular library.  I am virtually
positive that library (not only required for wingcc but also our cairo
device driver on Windows) is gdi32, but the warning diagnositics
provided by our build system are not currently detailed enough to
confirm that. So I have (as of revision 13120) updated those
diagnostics to be much more verbose when something is going wrong with
pkg-config so the library that is not found can at least be figured
out from those diagnostic messages.

So for the next iteration do an svn update first to get access to the
better warnings.  Also, if you are not following this good advice
already, please delete your old build tree and start over with an
empty build tree (so your build is not clobbered by bad stale results
that are cached from your previous failing attempts).

Note, I am pretty sure you will not have further trouble if you
provide CMake the obvious guidance it needs to find the gdi32 library.
Also, I must say that getting that guidance right was the most
difficult aspect of my own MinGW/Wine test case. In my case with
MinGW-4.7.2 the location of that library was in a subdirectory of the
MinGW install, i.e., z:/home/wine/newstart/MinGW-4.7.2/lib/libgdi32.a.
(and if I specified an alternative Windows system location that
appeared to contain a dll related to gdi32, that did not work in the
slightest with a run-time error message concerning a wrong library
format.)

So it was essential for me to set one component of the environment
variable CMAKE_LIBRARY_PATH to z:/home/wine/newstart/MinGW-4.7.2/lib
so that CMake would know to look in that directory for the gdi32
library that our build system needs.  I am pretty sure setting the
CMAKE_LIBRARY_PATH environment variable equivalently (using the
appropriate install prefix for wherever you installed MinGW) will
"just work" for you.

However, if not, I am game for at least one more iteration of remote
debugging if you continue to provide me with your cmake invocation,
cmake output, _and_ also add the relevant environment variables (I
have mentioned the complete list of those before in this thread) and the
CMakeCache.txt file in the top of the build tree that is generated by
the cmake command.  And if cmake is okay, but the further build is
not, then you should supply the additional VERBOSE=1 output from
that build.

> and now I can't
> even get pkg-config to work from the command.
>
> C:\walt\Software\Plplot\BUILD>dir C:\FortranTools\gtk\lib\pkgconfig\cairo.pc
> Volume in drive C has no label.
> Volume Serial Number is BADA-0412
>
> Directory of C:\FortranTools\gtk\lib\pkgconfig
>
> 09/21/2013  06:46 AM               409 cairo.pc
>               1 File(s)            409 bytes
>               0 Dir(s)  35,996,807,168 bytes free
>
> C:\walt\Software\Plplot\BUILD>pkg-config cairo

That is not the correct way to get library and cflags information
out of pkg-config.  Run

pkg-config --help

to see what is possible.  But to get all the library flags
for the cairo library you should invoke it as

pkg-config --libs cairo

and similarly the compile flags are determined using

pkg-config --cflags cairo

So make sure those commands give you sensible looking results which
tests that your PATH and possibly (if needed) your PKG_CONFIG_PATH
environment variables are set up properly to find cairo.  Note, this
is only a test and not part of the build since cmake calls pkg-config
internally using the PATH and PKG_CONFIG_PATH environment variables
you have set (and then transforms the results afterwards into the
form that is needed including dropping -lm for the Windows case).

Please see request above for all the information that is required
including all relevant environment variables if you have any troubles
for this iteration.  But I predict if there is a problem, then as soon
as you collect the requested information for me, you will probably
immediately understand and fix the problem with your setup.  :-)

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
__________________________

Re: [Plplot-general] Including cairo driver

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

Hi Walt:

Thanks for all these good questions below.  I am CCing the
plplot-general mailing list because I hope my answers will not only
help you but also others who are lurking on that list.

On 2014-05-14 12:57-0700 Walt Brainerd wrote:

> I found revision 13119--a bunch of stuff.
>
> What do I do with all that?

Probably the "bunch of stuff" is because you accessed everything in
our huge repository which includes all prior releases, all our branch
developments, and the trunk version.  Instead, you should just access
the trunk version alone.  The easiest way to do that is go to
sf.net/projects/plplot ==> code, and follow the directions there.

Your equivalent of the "svn --checkout" command for the svn trunk
version will create the source tree with a top-level directory named
with whatever name you decided on.  After that, create a build
directory outside the source tree, change to that (initially empty)
build directory, then execute the cmake command using the absolute
location of the top-level directory of the source tree and with
CMAKE_INSTALL_PREFIX set to an absolute location that is outside both
the source tree and the build tree.  Keeping those three trees
completely separate from each other is the most convenient way to
set up PLplot builds.

Using that method, your source tree remains absolutely pristine with
no non-source tree files put into it.  And it is easy to remove your
entire build tree after an install without interfering with the
install tree or source tree. Furthermore, whenever one of us updates
the svn trunk version, you can get access to that update by using the
equivalent of the svn --update command in the top-level of the source
tree with no revision specified.  The result will tell you what
revision number you updated to, and so long as that number is equal to
or greater than the revision number of our commits that you are
interested in, you should be fine (unless we screw up the svn trunk
version, but that happens rarely because that is the one that gets
daily use from the Plplot developers and that is the version of PLplot
that eventually becomes our next release after much comprehensive
testing using epa_build).

> My compiles have all been with 5.10.0.

The combination of a binary download of cairo + "MinGW Makefiles" is
absolutely cutting edge stuff (Principally, because I was unmotivated
to test that case before because it never worked for me.  But now it
does.  :-) )

Because this is cutting edge, it is required that you use the svn
trunk version of PLplot until our next release (probably something
like 6 months from now because we plan to move to a git repository,
and it will take a large effort on our part to adjust to that large
change).

> And do I have to worry about "epa_build",
> whatever that is ???

No, it is not necessary for you to use or be concerned about epa_build
at this time unless you want to do comprehensive testing.  But if you
are interested in comprehensive testing or are just plain curious at
all about the PLplot epa_build sub-project, I have documented in
cmake/epa_build/README the several reasons why I implemented it.

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
__________________________

Re: [Plplot-general] Including cairo driver

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

On 2014-05-14 06:34-0700 Walt Brainerd wrote:

> That sounds like you have made great progress.
>
> How exactly do I get cmake to filter out the -lm option?

You don't have to.  CMake provides a front-end for pkg-config (along
with a whole boat-load of other facilities) so after the pkg-config
results are delivered to our build system via cmake, I can then
manipulate them any way I like with cmake language logic (which I did
in revision 13116 to automatically drop -lm from the results).

>> As a workaround (revision 13116) for this gtk+ bug, I have filtered
>> -lm out of the above library flags for the Windows case (where the
>> cmake MATH_LIB variable is false).  As a result of this fix, cmake now
>> configures the cairo device without issues for the "MinGW Makefiles"
>> generator!

So all you have to do is repeat exactly what you did before with the
official 32-bit all-in-one binary version of GTK+ while using the
-G"MinGW Makefiles" -DDROP_GTK_PLUS_2_BUILDS=ON -DTEST_DYNDRIVERS=OFF
cmake options for the PLplot build, and all the cairo devices should
configure, build, and just work without ABI issues (at least for
my case of MinGW-4.7.2, but the MinGW developers normally go out of
their way not to introduce ABI changes so this will probably work
for all modern MinGW).

So please let me know how that goes.

>> I am now following up this cairo device driver success on MinGW by
>> starting a comprehensive interactive and non-interactive test on Wine
>> using the "MinGW Makefiles" generator and MSYS (a special version
>> without sh.exe in the PATH, see cmake/epa_build/README for how to
>> achieve that and why it is necessary).  The PLplot dependencies for
>> this test will be the binary download of gtk+ + epa_build of
>> everything else.  This test should take overnight on Wine, but it
>> should take roughly one-half hour on Microsoft Windows if anyone is
>> interested in following the directions in cmake/epa_build/README.

Walt, this further issue will likely not affect you unless you plan to
link your application with the installed version of PLplot using the
combination of make and pkg-config.  So please just go ahead with your
test, but for PLplot developers following this exchange the above
comprehensive test worked fine for the build tree and the CMake-based
build of the installed examples, but failed for the traditional build
(make plus pkg-config) of the installed examples.  Therefore, there is
a bit more work for me to do this morning to make this case (binary
download of GTK+ for a MinGW platform) work properly for that
traditional build.

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
__________________________

Re: [Plplot-general] Including cairo driver

[Walt B. <wal...@gm...>]

That sounds like you have made great progress.

How exactly do I get cmake to filter out the -lm option?


On Wed, May 14, 2014 at 4:32 AM, Alan W. Irwin <ir...@be...>wrote:

> On 2014-05-13 18:38-0700 Alan W. Irwin wrote:
>
>  On 2014-05-13 11:15-0700 Alan W. Irwin wrote:
>>
>>  Note, I have never gotten a downloaded binary version of GTK+ to work
>>> properly with PLplot on MinGW/Wine because of ABI incompatibility
>>> issues (my fairly recent version of MinGW was always ABI inconsistent
>>> with the typically extremely old version of MinGW used to build GTK+),
>>> but maybe I will finally get lucky this time.  Anyhow, so far so good,
>>> and more later as this experiment on Wine unfolds.
>>>
>>
>> Hi Walt:
>>
>> Six hours later (because the builds of PLplot dependencies on Wine are
>> really slow for the reasons I mentioned and one false start that
>> wasted a couple of hours) I finally got to the point of building
>> PLplot using the "MinGW Makefiles" generator against epa_built
>> versions of all its dependencies other than the GTK+ stack and the
>> official 32-bit binary version of GTK+ for Windows which is supposed
>> to be compatible with MinGW.
>>
>> The result verified the PLplot "MinGW Makefiles" build-system issue that
>> Walt found
>> previously on Microsoft Windows (which also verifies once again that
>> Wine is a fairly reliable but slow! Windows test platform); for some
>> strange reason parts of the GTK+ stack are being found by pkg-config but
>> other parts are not being found so the overall effect is the cairo
>> devices are all being dropped.  This pkg-config result works fine on
>> Linux so the whole thing is quite a puzzle.
>>
>> I will look further at this tomorrow (Wednesday) now I have confirmed
>> this Windows platform PLplot build-system (or perhaps pkg-config)
>> issue for the PLplot pango/cairo stack dependencies.
>>
>
> The issue turned out to be due to a GTK+ pkg-config configuration file bug
> where -lm is automatically added to the library links, e.g.,
>
> bash.exe-3.1$ pkg-config --libs pangocairo
> -Lz:/home/wine/gtkplus/3.6.4/lib -lpangocairo-1.0 -lcairo
>
> -lpangoft2-1.0 -lfreetype -lfontconfig -lpangowin32-1.0 -lgdi32
> -lpango-1.0 -lm -lgobject-2.0 -lglib-2.0 -lintl
>
> But the math library does not exist separately on Windows platforms so
> -lm should not be part of the link flags delivered by "pkg-config
> --libs pangocairo" (or the results of the equivalent CMake command
> which uses pkg-config internally).
>
> As a workaround (revision 13116) for this gtk+ bug, I have filtered
> -lm out of the above library flags for the Windows case (where the
> cmake MATH_LIB variable is false).  As a result of this fix, cmake now
> configures the cairo device without issues for the "MinGW Makefiles"
> generator!
>
> After that fix, I also ran into a number of additional minor build
> system issues for the "MinGW Makefiles" case and the cairo device
> driver case.  (The reason those issues existed is because that
> combination had not been tried in years.) I believe all of those
> issues are fixed now (revision 13119), and, for example, I can build
> (N.B. you must use the -DTEST_DYNDRIVERS=OFF cmake option) and run the
> wincairo device by hand without issues.
>
> So Walt, you should be able to do that now as well, but please let
> me know if you spot any other issue.  And thanks for being persistent
> with this issue so I finally fixed it!  :-)
>
> To everyone here, all preliminary indications are that (at least with
> MinGW-4.7.2 which is the version I am using) the official 32-bit
> binary download of cairo works well without ABI issues with PLplot.
> This is a first for me.  :-)
>
> I am now following up this cairo device driver success on MinGW by
> starting a comprehensive interactive and non-interactive test on Wine
> using the "MinGW Makefiles" generator and MSYS (a special version
> without sh.exe in the PATH, see cmake/epa_build/README for how to
> achieve that and why it is necessary).  The PLplot dependencies for
> this test will be the binary download of gtk+ + epa_build of
> everything else.  This test should take overnight on Wine, but it
> should take roughly one-half hour on Microsoft Windows if anyone is
> interested in following the directions in cmake/epa_build/README.
>
>
> 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
> __________________________
>



-- 
Walt Brainerd

Re: [Plplot-general] Including cairo driver

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

On 2014-05-13 18:38-0700 Alan W. Irwin wrote:

> On 2014-05-13 11:15-0700 Alan W. Irwin wrote:
>
>> Note, I have never gotten a downloaded binary version of GTK+ to work
>> properly with PLplot on MinGW/Wine because of ABI incompatibility
>> issues (my fairly recent version of MinGW was always ABI inconsistent
>> with the typically extremely old version of MinGW used to build GTK+),
>> but maybe I will finally get lucky this time.  Anyhow, so far so good,
>> and more later as this experiment on Wine unfolds.
>
> Hi Walt:
>
> Six hours later (because the builds of PLplot dependencies on Wine are
> really slow for the reasons I mentioned and one false start that
> wasted a couple of hours) I finally got to the point of building
> PLplot using the "MinGW Makefiles" generator against epa_built
> versions of all its dependencies other than the GTK+ stack and the
> official 32-bit binary version of GTK+ for Windows which is supposed
> to be compatible with MinGW.
>
> The result verified the PLplot "MinGW Makefiles" build-system issue that Walt found
> previously on Microsoft Windows (which also verifies once again that
> Wine is a fairly reliable but slow! Windows test platform); for some
> strange reason parts of the GTK+ stack are being found by pkg-config but
> other parts are not being found so the overall effect is the cairo
> devices are all being dropped.  This pkg-config result works fine on
> Linux so the whole thing is quite a puzzle.
>
> I will look further at this tomorrow (Wednesday) now I have confirmed
> this Windows platform PLplot build-system (or perhaps pkg-config)
> issue for the PLplot pango/cairo stack dependencies.

The issue turned out to be due to a GTK+ pkg-config configuration file bug
where -lm is automatically added to the library links, e.g.,

bash.exe-3.1$ pkg-config --libs pangocairo
-Lz:/home/wine/gtkplus/3.6.4/lib -lpangocairo-1.0 -lcairo
-lpangoft2-1.0 -lfreetype -lfontconfig -lpangowin32-1.0 -lgdi32
-lpango-1.0 -lm -lgobject-2.0 -lglib-2.0 -lintl

But the math library does not exist separately on Windows platforms so
-lm should not be part of the link flags delivered by "pkg-config
--libs pangocairo" (or the results of the equivalent CMake command
which uses pkg-config internally).

As a workaround (revision 13116) for this gtk+ bug, I have filtered
-lm out of the above library flags for the Windows case (where the
cmake MATH_LIB variable is false).  As a result of this fix, cmake now
configures the cairo device without issues for the "MinGW Makefiles"
generator!

After that fix, I also ran into a number of additional minor build
system issues for the "MinGW Makefiles" case and the cairo device
driver case.  (The reason those issues existed is because that
combination had not been tried in years.) I believe all of those
issues are fixed now (revision 13119), and, for example, I can build
(N.B. you must use the -DTEST_DYNDRIVERS=OFF cmake option) and run the
wincairo device by hand without issues.

So Walt, you should be able to do that now as well, but please let
me know if you spot any other issue.  And thanks for being persistent
with this issue so I finally fixed it!  :-)

To everyone here, all preliminary indications are that (at least with
MinGW-4.7.2 which is the version I am using) the official 32-bit
binary download of cairo works well without ABI issues with PLplot.
This is a first for me.  :-)

I am now following up this cairo device driver success on MinGW by
starting a comprehensive interactive and non-interactive test on Wine
using the "MinGW Makefiles" generator and MSYS (a special version
without sh.exe in the PATH, see cmake/epa_build/README for how to
achieve that and why it is necessary).  The PLplot dependencies for
this test will be the binary download of gtk+ + epa_build of
everything else.  This test should take overnight on Wine, but it
should take roughly one-half hour on Microsoft Windows if anyone is
interested in following the directions in cmake/epa_build/README.

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
__________________________

Re: [Plplot-general] Including cairo driver

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

On 2014-05-13 11:15-0700 Alan W. Irwin wrote:

> Note, I have never gotten a downloaded binary version of GTK+ to work
> properly with PLplot on MinGW/Wine because of ABI incompatibility
> issues (my fairly recent version of MinGW was always ABI inconsistent
> with the typically extremely old version of MinGW used to build GTK+),
> but maybe I will finally get lucky this time.  Anyhow, so far so good,
> and more later as this experiment on Wine unfolds.

Hi Walt:

Six hours later (because the builds of PLplot dependencies on Wine are
really slow for the reasons I mentioned and one false start that
wasted a couple of hours) I finally got to the point of building
PLplot using the "MinGW Makefiles" generator against epa_built
versions of all its dependencies other than the GTK+ stack and the
official 32-bit binary version of GTK+ for Windows which is supposed
to be compatible with MinGW.

The result verified the PLplot "MinGW Makefiles" build-system issue that Walt found
previously on Microsoft Windows (which also verifies once again that
Wine is a fairly reliable but slow! Windows test platform); for some
strange reason parts of the GTK+ stack are being found by pkg-config but
other parts are not being found so the overall effect is the cairo
devices are all being dropped.  This pkg-config result works fine on
Linux so the whole thing is quite a puzzle.

I will look further at this tomorrow (Wednesday) now I have confirmed
this Windows platform PLplot build-system (or perhaps pkg-config)
issue for the PLplot pango/cairo stack dependencies.

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
__________________________

Re: [Plplot-general] Including cairo driver

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

On 2014-05-13 09:38-0700 Alan W. Irwin wrote:

> I am now going to try the official all-in-on bundle of GTK+ accessible
> at http://www.gtk.org/download/win32.php under Wine with the PLplot
> svn trunk version and with -DDROP_GTK_PLUS_2_BUILDS=ON to see how far
> I get.

Hi Walt:

Here are some notes for this process as I go along.

I unpacked the bundle in a non-system location
(/z/home/wine/gtkplus/3.6.4), and then
finished the install using the directions in
gtk+-bundle_3.6.4-20130921_win32.README.txt.  Those instructions
translated (under MSYS and with the above install location) to the
following:

# Follow directions in gtk+-bundle_3.6.4-20130921_win32.README.txt but
# with MSYS PATHs for GTK+ put last so that you use pkg-config version
# from epa_build, for example.

bash.exe-3.1$ PATH=$PATH:/z/home/wine/gtkplus/3.6.4/bin
bash.exe-3.1$ PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/z/home/wine/gtkplus/3.6.4/lib/pkgconfig
bash.exe-3.1$ pkg-config --cflags gtk+-3.0
-mms-bitfields -Iz:/home/wine/gtkplus/3.6.4/include/gtk-3.0 -Iz:/home/wine/gtkplus/3.6.4/include/cairo -Iz:/home/wine/gtkplus/3.6.4/include/
pango-1.0 -Iz:/home/wine/gtkplus/3.6.4/include/atk-1.0 -Iz:/home/wine/gtkplus/3.6.4/include/cairo -Iz:/home/wine/gtkplus/3.6.4/include/pixma
n-1 -Iz:/home/wine/gtkplus/3.6.4/include -Iz:/home/wine/gtkplus/3.6.4/include/freetype2 -Iz:/home/wine/gtkplus/3.6.4/include -Iz:/home/wine/
gtkplus/3.6.4/include/libpng15 -Iz:/home/wine/gtkplus/3.6.4/include/gdk-pixbuf-2.0 -Iz:/home/wine/gtkplus/3.6.4/include/libpng15 -Iz:/home/w
ine/gtkplus/3.6.4/include/glib-2.0 -Iz:/home/wine/gtkplus/3.6.4/lib/glib-2.0/include
bash.exe-3.1$ pango-querymodules > /z/home/wine/gtkplus/3.6.4/etc/pango/pango.modules
bash.exe-3.1$ gdk-pixbuf-query-loaders > /z/home/wine/gtkplus/3.6.4/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
bash.exe-3.1$ gtk-query-immodules-3.0 > /z/home/wine/gtkplus/3.6.4/lib/gtk-3.0/3.0.0/immodules.cache

Following those directions, I then tested the result:

bash.exe-3.1$ gtk3-demo

I didn't check everything, but what I did check, e.g., the colour chooser, worked
fine.

Note the above is for my preferred MSYS bash.exe working environment,
and the form of the PATHs change (see
gtk+-bundle_3.6.4-20130921_win32.README.txt for that case) for the
more typical case where you are using raw Windows without MSYS. Also,
the above notes are for the case where I am already using the
epa_build version of pkg-config with PKG_CONFIG_PATH already setup to
work properly for the non-GTK+ case.  For the more likely scenario
where you just use pkg-config.exe from the gtk+ bundle, and you have
no other component of PLplot that you are configuring with pkg-config,
then you should simply drop setting PKG_CONFIG_PATH.

Note, I have never gotten a downloaded binary version of GTK+ to work
properly with PLplot on MinGW/Wine because of ABI incompatibility
issues (my fairly recent version of MinGW was always ABI inconsistent
with the typically extremely old version of MinGW used to build GTK+),
but maybe I will finally get lucky this time.  Anyhow, so far so good,
and more later as this experiment on Wine unfolds.

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
__________________________

Re: [Plplot-general] Including cairo driver

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

On 2014-05-10 08:16-0700 Walt Brainerd wrote:

> Since the cygwin build appears to work, I sent only
> the Mingw files. Note from the cmake command
> the -G option and the use of the cmake recommended
> to me by Darius. I completely disabled alll cygwin
> files when doing that build
>
> I got GTK at www.tarnyko.net/dl and downloaded and
> unzipped the GTK+3.6.4 Bundle for Windows that is
> right at the top of the page.

Hi Walt:

I am fairly sure the unofficial versions of GTK+ at www.tarnyko.net/dl
are the same as the official versions accessible at
http://www.gtk.org/download/win64.php and
http://www.gtk.org/download/win32.php, but in any case you should be
using only the latter, the official 32-bit version rather than a
64-bit version (official or unofficial) or an unofficial 32-bit
version from www.tarnyko.net/dl. (See the remarks at
http://www.gtk.org/download/win64.php concerning the experimental
nature of the 64-bit version and its known incompatibility with MinGW.
And, for now do not use mingw-64 (an additional platform beyond Cygwin
and MinGW which is substantially different than MinGW) since we have
zero experience with mingw-64.)

Also, the cmake command you reported, i.e.,

C:\"Program Files (x86)"\"CMake 2.8"\bin\cmake -G "MinGW Makefiles"
-DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON
-DENABLE_DYNDRIVERS=ON -DCMAKE
INSTALL_PREFIX=install .. 1>cmake.out 2>cmake.err

is not quite right.  That option should instead be

-DCMAKE_INSTALL_PREFIX=install

Furthermore, you must use the svn trunk version of PLplot which
contains our latest build-system changes for the GTK+ version 3 case.
The PLplot build system for that version of GTK+ is still a bit rough
so instead of figuring things out for itself you have to explicitly
use the

-DDROP_GTK_PLUS_2_BUILDS=ON

cmake option to drop minor parts of the PLplot build that are not
compatible with GTK+ version 3.

I am now going to try the official all-in-on bundle of GTK+ accessible
at http://www.gtk.org/download/win32.php under Wine with the PLplot
svn trunk version and with -DDROP_GTK_PLUS_2_BUILDS=ON to see how far
I get. But please try that yourself at the same time rather than
waiting for me since Wine has severe startup latency for every command
that (assuming it works) is going to significantly delay when I can
get back to you with the result to compare to yours (which might work
right out of the box).  This Wine startup latency doesn't matter a bit
for long tasks such as running a game, but for build and test tasks
that might easily require 0.1 million short commands to run, the
startup latency of typically 0.3-0.5 seconds for each of those
commands takes a huge toll (roughly 10-15 hours) for a build and test
task that should take only 0.5 hours on Microsoft Windows.

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
__________________________

Re: [Plplot-general] Including cairo driver

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

On 2014-05-09 15:39-0700 Walt Brainerd wrote:

> I have now built Plplot using cygwin. The cairo dirvers show up.
> I think the problem was resolved by disabling other things on my
> system, mainly Mingw (Fortran Tools), but also Absoft, Intel, and
> G95 Fortran compilers. I don't know how to use the cairo driver, but
> will work on that.
>
> I don't think this helps me build Plplot for inclusion in the Fortran
> Tools because the FT do not include cygwin (just Mingw). So I
> am trying to attach all the stuff requested. I don't think this is a
> bug report, just a problem trying to get everything set up OK.

Hi Walt:

Please clarify.  Is your report for Cygwin or MinGW?

Also, what is the source of the files in
C:\FortranTools\gtk\lib\pkgconfig ?

Is that from a Cygwin install or something else?  If something else,
what exactly, i.e., where could I download it myself?

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
__________________________

Re: [Plplot-general] Including cairo driver

[Walt B. <wal...@gm...>]

I should have added that when I built using Mingw,
I disabled cygwin (as well as all the other Fortran
compilers).


On Fri, May 9, 2014 at 3:39 PM, Walt Brainerd <wal...@gm...>wrote:

> I have now built Plplot using cygwin. The cairo dirvers show up.
> I think the problem was resolved by disabling other things on my
> system, mainly Mingw (Fortran Tools), but also Absoft, Intel, and
> G95 Fortran compilers. I don't know how to use the cairo driver, but
> will work on that.
>
> I don't think this helps me build Plplot for inclusion in the Fortran
> Tools because the FT do not include cygwin (just Mingw). So I
> am trying to attach all the stuff requested. I don't think this is a
> bug report, just a problem trying to get everything set up OK.
>
> The command to build is:
> C:\"Program Files (x86)"\"CMake 2.8"\bin\cmake -G "MinGW Makefiles"
> -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON
> -DENABLE_DYNDRIVERS=ON -DCMAKE
> INSTALL_PREFIX=install .. 1>cmake.out 2>cmake.err
>
> all one line, of course. The files cmake.??? are in the tar ball attached.
> Also the output from make.
>
> The lines that say that pango and cairo can't be found (after finding
> them--see cmake.out) surely are suspicious. Here is a bit more about
> that checking on what Darius said:
>
> C:\walt>echo %PKG_CONFIG_PATH%
> C:\FortranTools\gtk\lib\pkgconfig
>
> C:\walt>dir C:\FortranTools\gtk\lib\pkgconfig\pango*
>  Volume in drive C has no label.
>  Volume Serial Number is BADA-0412
>
>  Directory of C:\FortranTools\gtk\lib\pkgconfig
>
> 04/20/2013  05:24 AM               330 pango.pc
> 04/20/2013  05:24 AM               283 pangocairo.pc
> 04/20/2013  05:24 AM               303 pangoft2.pc
> 04/20/2013  05:24 AM               263 pangowin32.pc
>                4 File(s)          1,179 bytes
>                0 Dir(s)  37,579,841,536 bytes free
>
> C:\walt>dir C:\FortranTools\gtk\lib\pkgconfig\cairo*
>  Volume in drive C has no label.
>  Volume Serial Number is BADA-0412
>
>  Directory of C:\FortranTools\gtk\lib\pkgconfig
>
> 04/20/2013  05:14 AM               262 cairo-fc.pc
> 04/20/2013  05:14 AM               259 cairo-ft.pc
> 04/20/2013  05:14 AM               288 cairo-gobject.pc
> 04/20/2013  05:14 AM               242 cairo-pdf.pc
> 04/20/2013  05:14 AM               239 cairo-png.pc
> 04/20/2013  05:14 AM               248 cairo-ps.pc
> 04/20/2013  05:14 AM               239 cairo-svg.pc
> 04/20/2013  05:14 AM               257 cairo-win32-font.pc
> 04/20/2013  05:14 AM               255 cairo-win32.pc
> 04/20/2013  05:14 AM               374 cairo.pc
>               10 File(s)          2,663 bytes
>                0 Dir(s)  37,578,792,960 bytes free
>
> so there is all kinds of cairo and pango stuff there. And
> the following also seems to work . . .
>
> C:\walt>pkg-config --libs pango
> -LC:/FortranTools/gtk/lib -lpango-1.0 -lm -lgobject-2.0 -lglib-2.0 -lintl
>
> C:\walt>pkg-config --libs cairo
> -LC:/FortranTools/gtk/lib -lcairo
>
> and gtk-demo works OK.
>
> Files printenv.out, cmake.out, cmake.err,
> make.out, and make.err (empty) are attached
> in walt.tar.gz. Rename it from walt_tar_gz.
>
> Thanks for looking at this. Let me know if you
> need anything else.
>
>
>
> On Sun, May 4, 2014 at 11:33 AM, Alan W. Irwin <ir...@be...>wrote:
>
>> On 2014-05-04 09:12-0700 Walt Brainerd wrote:
>>
>>  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.
>>>
>>
>> Yes, please.  Often the PLplot build problem is something really simple,
>> but we
>> cannot help you figure that out without comprehensive information from
>> you containing all the details.  Only some of those details will be
>> relevant, but we don't know which until we see all of them. Without
>> such comprehensive details, we speculate as to what the issue is, you
>> respond, we speculate again, etc., and those iterations consume
>> a lot of time for both parties.
>>
>> So here is the comprehensive information that I would really like to
>> see in a typical bug report from you and others here so that we have a
>> good chance to help you while minimizing iterations.
>>
>> 1. List all environment variables.  (This is important since some of
>> those environment variables affect cmake's operation.) On Unix or if
>> you have MSYS installed this can be done with
>>
>> printenv >printenv.out
>>
>> but otherwise, output any PATH, CMAKE_LIBRARY_PATH,
>> CMAKE_INCLUDE_PATH, PKG_CONFIG_PATH, CC, CXX, FC, CFLAGS, CXXFLAGS, and
>> FFLAGS
>> environment variables you have set to a file, and include that file in
>> your bug report.
>>
>> 2. Give the exact command you used to invoke cmake.
>>
>> 3. Give the output from that command captured, e.g., in the cmake.out file
>> using
>>
>> cmake <whatever options> <source tree> >& cmake.out
>>
>> where <whatever options> and <source tree> are given in detail in 2.
>>
>> The above is a good way to capture stderr and stdout in a file
>> simultaneously on Unix, Cygwin, or for MSYS, but I am sure there is also
>> a way to capture stderr and stdout for a cl-based native Windows
>> environment,
>> but I don't know what that is.
>>
>> 4. Include the resulting CMakeCache.txt file (from the top directory in
>> the
>> build tree).
>>
>> 5. Give the exact build command you used (with VERBOSE=1 set)
>>
>> For example, on Unix, Cygwin, or MSYS that could be
>>
>> make VERBOSE=1 all >& all.out
>>
>> and on native Windows it would be
>>
>> nmake VERBOSE=1 all >& all.out
>>
>> (where ">&" stands symbolically for whatever means are necessary to
>> capture stderr and stdout on Windows in the all.out file).
>>
>> 6. Give the output from the build command (e.g., all.out in the example
>> just above).
>>
>> Then collect all these requested files in a compressed tarball and
>> send it to this list along with the cmake and build command invocation
>> information requested in 2 and 5.
>>
>> I hope these detailed instructions for reporting any PLplot build
>> problems will be a help to you and everyone else on this list.
>>
>>
>> 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
>> __________________________
>>
>
>
>
> --
> Walt Brainerd
>



-- 
Walt Brainerd

[Plplot-general] Trying plplot

[Walt B. <wal...@gm...>]

program ft_x00f

! This is a modified version of x00f.f90
! which was written by Alan Irwin

   use plplot
   implicit none

   integer, parameter :: NSIZE = 100

   real(kind=plflt), dimension(0:NSIZE) :: x, y

   real(kind=plflt) :: xmin =   0.0_plflt, &
                       xmax =   1.0_plflt, &
                       ymin =   0.0_plflt, &
                       ymax = 100.0_plflt
   integer :: i

   ! Prepare data to be plotted.
   ! x = .00, .01, .02, ..., .99, 1.00
   x = [(i, i=0,NSIZE)] / real(NSIZE)
   y = ymax * x**2

   ! Parse and process command line arguments
   call plparseopts( PL_PARSE_FULL )

   ! Initialize plplot
   call plinit( )

   ! Create a labelled box to hold the plot.
   call plenv( xmin, xmax, ymin, ymax, just=0, axis=0 )
   call pllab( "x", "y=100 x#u2#d", &
               "Simple PLplot demo of a 2D line plot" )

   ! Plot the data that was prepared above.
   call plline( x, y )

   ! Close PLplot library
   call plend( )

end program ft_x00f

Re: [Plplot-general] GTK and Plplot using plplotcanvas.

[Hazen B. <hba...@ma...>]

> PS: anyone know any other example of use between gtk and plplot? i found
> some cairo mentions but cairo only shows 2D graphs and maybe i will need 3D
> capabilities at the near future :).

I believe that gcw / gnome driver (and plplotcanvas) are no longer 
supported.

PLplot can create 3D graphs using the cairo driver. You won't be able to 
manipulate them with the mouse in real time (i.e. rotate them, etc.) 
like you would be able to with a OpenGL scene or equivalent, but this is 
also true of all of the other PLplot drivers. I would recommend the 
cairo driver (extcairo) for GTK applications and the qt driver (extqt) 
for Qt applications.

-Hazen

[Plplot-general] GTK and Plplot using plplotcanvas.

[manel c. <man...@gm...>]

I am trying to embed a plplot program inside a window using gtk, my first
attempt was unsuccessful. I tried with a little example coda at the plplot
documentation page.

#include <plplotcanvas.h>
    #include <libgnomecanvas/libgnomecanvas.h>
    #include <gtk/gtk.h>
    #include <stdio.h>
    #include <string.h>
    #include <stdlib.h>
    #include <plplot.h>

    /* The width and height of the plplot canvas widget */
    #define WIDTH 1000 /* 500 */
    #define HEIGHT 600 /* 300 */

    /* Delete event callback */
    gint delete_event( GtkWidget *widget,GdkEvent *event,gpointer data ) {
    return FALSE;
    }

    /* Destroy event calback */
    void destroy(GtkWidget *widget,gpointer data) {
    gtk_main_quit ();
    }


    int main(int argc,char *argv[] )
    {

    PlplotCanvas* canvas;
    GtkWidget *window;

    /* Parse the options */
    plparseopts(&argc, argv, PL_PARSE_FULL);

    /* The data to plot */
    double x[11] = {0,1,2,3,4,5,6,7,8,9,10};
    double y[11] = {0,0.1,0.4,0.9,1.6,2.6,3.6,4.9,6.4,8.1,10};

    /* Initialize gtk and the glib type system */
    gtk_init(&argc, &argv);
    g_type_init();

    /* Create the canvas and set its size; during the creation process,
    * the gcw driver is loaded into plplot, and plinit() is invoked.
    */
    canvas=plplot_canvas_new(TRUE);
    plplot_canvas_set_size(canvas,WIDTH,HEIGHT);

    /* Create a new window and stuff the canvas into it */
    window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_container_set_border_width(GTK_CONTAINER(window),10);
    gtk_container_add(GTK_CONTAINER(window),GTK_WIDGET(canvas));

    /* Connect the signal handlers to the window decorations */
    g_signal_connect(G_OBJECT(window),"delete_event",
    G_CALLBACK(delete_event),NULL);
    g_signal_connect(G_OBJECT(window),"destroy",G_CALLBACK(destroy),NULL);

    /* Display everything */
    gtk_widget_show_all(window);

    /* Draw on the canvas with Plplot */
    plplot_canvas_pladv(canvas,0); /* Advance to first page */
    plplot_canvas_plcol0(canvas,15); /* Set color to black */
    plplot_canvas_plwid(canvas,2); /* Set the pen width */
    plplot_canvas_plvsta(canvas); /* Set the viewport */
    plplot_canvas_plwind(canvas,0.,10.,0.,10.); /* Set the window */
    plplot_canvas_plbox(canvas,"bcnst",0.,0,"bcnstv",0.,0); /* Set the box */
    plplot_canvas_pllab(canvas,"x-axis","y-axis","A Simple Plot"); /*
Draw some labels */

    /* Draw the line */
    plplot_canvas_plcol0(canvas,1); /* Set the pen color */
    plplot_canvas_plline(canvas,11,x,y);

    /* Advancing the page finalizes this plot */
    plplot_canvas_pladv(canvas,0);

    /* Start the gtk main loop */
    gtk_main();
    }

compiling:

gcc `pkg-config --cflags --libs plplotd gtk+-2.0` plem.c -o plem

i get the next error:

In file included from plem.c:1:In file included from
/usr/local/Cellar/plplot/5.10.0/include/plplot/plplotcanvas.h:33:/usr/local/Cellar/plplot/5.10.0/include/plplot/gcw.h:38:10:
fatal error: 'libgnomecanvas/libgnomecanvas.h' file not found

I found the libgnomecanvas using:

find / -name "libgnomecanvas.h"

The file is at:

/usr/local/Cellar/libgnomecanvas/2.30.3/include/libgnomecanvas-2.0/libgnomecanvas/libgnomecanvas.h

I changed the include to

#include"/usr/local/Cellar/libgnomecanvas/2.30.3/include/libgnomecanvas-2.0/libgnomecanvas/libgnomecanvas.h"

Then i get more errors because libgnomecanvas.h can not locate the
libraries at the same folder. I tried to change all the includes and the
same error again and again (maybe it was the wrong approach… a little dumb
i think). Then i tried to use the compile instructions at the manual:
http://archive.tcltk.co.kr/doc/plplot-html-5.9.4/gui.html

I compile with this:

gcc plem.c -o plem `PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
pkg-config --cflags --libs plplotd-gnome2`

Then i get:

Package plplotd-gnome2 was not found in the pkg-config search
path.Perhaps you should add the directory containing
`plplotd-gnome2.pc'
to the PKG_CONFIG_PATH environment variableNo package 'plplotd-gnome2' found
plem.c:1:11: fatal error: 'plplotcanvas.h' file not found
        #include <plplotcanvas.h>

So i try to find plplotd-gnome2.pc but i have not success at all (not
installed). Then back to my files i found the pkgconfig file of
libgnocanvas and i execute export pgkconfig and again the same error a new
one. I am a little bit confused right now :S. Any idea about what is
happening here and how i can fix it?. Thanks in advance guys and have a
nice day!


PS: anyone know any other example of use between gtk and plplot? i found
some cairo mentions but cairo only shows 2D graphs and maybe i will need 3D
capabilities at the near future :).

Re: [Plplot-general] Including cairo driver

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

On 2014-05-04 09:12-0700 Walt Brainerd wrote:

> 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.

Yes, please.  Often the PLplot build problem is something really simple, but we
cannot help you figure that out without comprehensive information from
you containing all the details.  Only some of those details will be
relevant, but we don't know which until we see all of them. Without
such comprehensive details, we speculate as to what the issue is, you
respond, we speculate again, etc., and those iterations consume
a lot of time for both parties.

So here is the comprehensive information that I would really like to
see in a typical bug report from you and others here so that we have a
good chance to help you while minimizing iterations.

1. List all environment variables.  (This is important since some of
those environment variables affect cmake's operation.) On Unix or if
you have MSYS installed this can be done with

printenv >printenv.out

but otherwise, output any PATH, CMAKE_LIBRARY_PATH,
CMAKE_INCLUDE_PATH, PKG_CONFIG_PATH, CC, CXX, FC, CFLAGS, CXXFLAGS, and FFLAGS
environment variables you have set to a file, and include that file in
your bug report.

2. Give the exact command you used to invoke cmake.

3. Give the output from that command captured, e.g., in the cmake.out file
using

cmake <whatever options> <source tree> >& cmake.out

where <whatever options> and <source tree> are given in detail in 2.

The above is a good way to capture stderr and stdout in a file
simultaneously on Unix, Cygwin, or for MSYS, but I am sure there is also
a way to capture stderr and stdout for a cl-based native Windows environment,
but I don't know what that is.

4. Include the resulting CMakeCache.txt file (from the top directory in the
build tree).

5. Give the exact build command you used (with VERBOSE=1 set)

For example, on Unix, Cygwin, or MSYS that could be

make VERBOSE=1 all >& all.out

and on native Windows it would be

nmake VERBOSE=1 all >& all.out

(where ">&" stands symbolically for whatever means are necessary to
capture stderr and stdout on Windows in the all.out file).

6. Give the output from the build command (e.g., all.out in the example just above).

Then collect all these requested files in a compressed tarball and
send it to this list along with the cmake and build command invocation
information requested in 2 and 5.

I hope these detailed instructions for reporting any PLplot build
problems will be a help to you and everyone else on this list.

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
__________________________

Re: [Plplot-general] Including cairo driver

[Walt B. <wal...@gm...>]

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 <Arj...@de...>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:wal...@gm...]
> *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 <ir...@be...>
> 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
> Plp...@li...
> 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

Re: [Plplot-general] Including cairo driver

[Arjen M. <Arj...@de...>]

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:wal...@gm...]
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 <ir...@be...<mailto:ir...@be...>> 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<http://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<http://astrowww.phys.uvic.ca>).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net<http://freeeos.sf.net>); the Time
Ephemerides project (timeephem.sf.net<http://timeephem.sf.net>); PLplot scientific plotting
software package (plplot.sf.net<http://plplot.sf.net>); the libLASi project
(unifont.org/lasi<http://unifont.org/lasi>); the Loads of Linux Links project (loll.sf.net<http://loll.sf.net>);
and the Linux Brochure Project (lbproject.sf.net<http://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
Plp...@li...<mailto:Plp...@li...>
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.