plplot-devel

[Plplot-devel] Plplot now working well with Debian Buster + release timing

[Alan W. I. <Ala...@gm...>]

To Orion and Ole:

Commit a730ebe34 has removed the last of the "new software" issues I
have identified with Debian Testing = Buster.

@Orion: I encourage you to try that commit on Fedora to see if you get
similarly good results for all Linux-available components of
PLplot for that other cutting-edge Linux platform.

@Both: You both also might want to experiment with this commit as the
basis for much-improved PLplot packages for Fedora and Debian.
However such packages can only be considered preliminary until PLplot
makes an official release.  What I can say on that topic is commit
a730ebe34 is an important milestone on the trail to the next release,
but we are not there yet.

For example, the CMake test that is automatically produced every night
by my computer for the CMake developers builds and tests the latest
CMake.  One of those tests is the PLplot contract test which tests
whether a build (but not test) of PLplot is successful.  That test is
formally succeeding, but those PLplot builds are incomplete (with the
cairo device driver dropped) because of incompatibilities with the way
we configure our cairo device driver using internal details of the
CMake pkg-config capability.  Although the use of such internal
details has worked well over many years with few adjustments needed
for changes to those internal details with CMake version, it is again
no longer working with the very latest CMake.  This reflects the
fundamental fragility of any method that uses internal details.
Therefore, to deal with this issue my plan is to completely rewrite
our support for the cairo device using the official CMake pkg-config
support rather than internal details of that support.  And there are
also a few other topics I would like to squeeze into the next release.
So this makes the ETA of our next PLplot release still somewhat
uncertain, but I am still hoping to get it done this year (before
Christmas season) rather than early next year.

Alan
__________________________
Alan W. Irwin

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-devel] Plplot now working well with Debian Buster + release timing

[Orion P. <or...@nw...>]

On 09/15/2018 01:49 PM, Alan W. Irwin wrote:
> To Orion and Ole:
> 
> Commit a730ebe34 has removed the last of the "new software" issues I
> have identified with Debian Testing = Buster.
> 
> @Orion: I encourage you to try that commit on Fedora to see if you get
> similarly good results for all Linux-available components of
> PLplot for that other cutting-edge Linux platform.
> 
> @Both: You both also might want to experiment with this commit as the
> basis for much-improved PLplot packages for Fedora and Debian.
> However such packages can only be considered preliminary until PLplot
> makes an official release.  What I can say on that topic is commit
> a730ebe34 is an important milestone on the trail to the next release,
> but we are not there yet.
> 
> For example, the CMake test that is automatically produced every night
> by my computer for the CMake developers builds and tests the latest
> CMake.  One of those tests is the PLplot contract test which tests
> whether a build (but not test) of PLplot is successful.  That test is
> formally succeeding, but those PLplot builds are incomplete (with the
> cairo device driver dropped) because of incompatibilities with the way
> we configure our cairo device driver using internal details of the
> CMake pkg-config capability.  Although the use of such internal
> details has worked well over many years with few adjustments needed
> for changes to those internal details with CMake version, it is again
> no longer working with the very latest CMake.  This reflects the
> fundamental fragility of any method that uses internal details.
> Therefore, to deal with this issue my plan is to completely rewrite
> our support for the cairo device using the official CMake pkg-config
> support rather than internal details of that support.  And there are
> also a few other topics I would like to squeeze into the next release.
> So this makes the ETA of our next PLplot release still somewhat
> uncertain, but I am still hoping to get it done this year (before
> Christmas season) rather than early next year.

Latest git (a9d9500c) built on Fedora Rawhide:

https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905

Despite the overall failure to build, looks mostly okay, but it appears 
that you don't support lua 5.3:

-- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
version "5.2")
-- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
version "5.1")
-- LUA_INCLUDE_DIR =
-- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so
-- WARNING: Lua header and/or library not found. Disabling Lua binding


-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Plplot-devel] Plplot now working well with Debian Buster + release timing

[Alan W. I. <Ala...@gm...>]

On 2018-09-19 22:06-0600 Orion Poplawski wrote:

> On 09/15/2018 01:49 PM, Alan W. Irwin wrote:
>> To Orion and Ole:
>> 
>> Commit a730ebe34 has removed the last of the "new software" issues I
>> have identified with Debian Testing = Buster.
>> 
>> @Orion: I encourage you to try that commit on Fedora to see if you get
>> similarly good results for all Linux-available components of
>> PLplot for that other cutting-edge Linux platform.
>> 
>> @Both: You both also might want to experiment with this commit as the
>> basis for much-improved PLplot packages for Fedora and Debian.
>> However such packages can only be considered preliminary until PLplot
>> makes an official release.  What I can say on that topic is commit
>> a730ebe34 is an important milestone on the trail to the next release,
>> but we are not there yet.
>> 
>> For example, the CMake test that is automatically produced every night
>> by my computer for the CMake developers builds and tests the latest
>> CMake.  One of those tests is the PLplot contract test which tests
>> whether a build (but not test) of PLplot is successful.  That test is
>> formally succeeding, but those PLplot builds are incomplete (with the
>> cairo device driver dropped) because of incompatibilities with the way
>> we configure our cairo device driver using internal details of the
>> CMake pkg-config capability.  Although the use of such internal
>> details has worked well over many years with few adjustments needed
>> for changes to those internal details with CMake version, it is again
>> no longer working with the very latest CMake.  This reflects the
>> fundamental fragility of any method that uses internal details.
>> Therefore, to deal with this issue my plan is to completely rewrite
>> our support for the cairo device using the official CMake pkg-config
>> support rather than internal details of that support.  And there are
>> also a few other topics I would like to squeeze into the next release.
>> So this makes the ETA of our next PLplot release still somewhat
>> uncertain, but I am still hoping to get it done this year (before
>> Christmas season) rather than early next year.
>
> Latest git (a9d9500c) built on Fedora Rawhide:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905
>
> Despite the overall failure to build, looks mostly okay, but it appears that 
> you don't support lua 5.3:
>
> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version 
> "5.2")
> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version 
> "5.1")
> -- LUA_INCLUDE_DIR =
> -- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so
> -- WARNING: Lua header and/or library not found. Disabling Lua binding

Hi Orion:

Thanks for that feedback.  Lua5.3 worked here (Debian Testing = Buster)
for all but one example, but that one example exposed a Lua-5.3 bug
(at least for the Debian version of Lua5.3) that was severe
(arithmetic quit working if more than 8 (!) arrays were initialized).
See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for a
simple Lua script that triggers this Lua-5.3 bug and other details
about this bug.  I temporarily worked around the problem by using our
build system to blacklist Lua-5.3 until this bug is fixed (i.e.,
in the absence of Lua5.1 or 5.2 our build system should just
cleanly drop the Lua PLplot component and continue).

Please try that simple Lua script to see whether the Fedora version of
Lua-5.3 also has this severe bug.  If you do confirm, then that is
pretty good evidence it is a general Lua-5.3 bug (rather than just
Debian related), and in this case I would be willing to take this
issue to the Lua developers rather than waiting for some response to
my bug report from the Debian packagers.

It appears from
<https://kojipkgs.fedoraproject.org//work/tasks/1906/29771906/build.log>
the blacklisting worked without actual build issues (as expected), but
the actual error you get is because your rpm logic is expecting Lua
files from PLplot that are not there because of the blacklisting.  So
your response to this issue likely depends on whether you can get the
above simple test script to work for Fedora's version of Lua5.3.  If
that test actually works for Fedora, then it appears the Lua5.3 issue
is simply a Debian packaging issue that has nothing to do with Fedora,
and you should edit cmake/modules/lua.cmake to make the slight change
to look first for 5.3, then 5.2, then 5.1.  However, if that test also
fails for you, and you think the upstream Lua5.3 fix is going to take
a while to get fixed, then you should change your rpm logic to drop
all the expected Lua results.

Alan
__________________________
Alan W. Irwin

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-devel] Plplot now working well with Debian Buster + release timing

[Ole S. <deb...@li...>]

Hi Alan,

I am very happy to read this, however I am currently stuck with a
problem that I can't build the package due to a problem in octave
<https://bugs.debian.org/906047> which is still unresolved in
unstable. Once this is fixed, I will upload a new package.

Thank you very much for your efforts!

Best

Ole

"Alan W. Irwin" <Ala...@gm...> writes:

> To Orion and Ole:
>
> Commit a730ebe34 has removed the last of the "new software" issues I
> have identified with Debian Testing = Buster.
>
> @Orion: I encourage you to try that commit on Fedora to see if you get
> similarly good results for all Linux-available components of
> PLplot for that other cutting-edge Linux platform.
>
> @Both: You both also might want to experiment with this commit as the
> basis for much-improved PLplot packages for Fedora and Debian.
> However such packages can only be considered preliminary until PLplot
> makes an official release.  What I can say on that topic is commit
> a730ebe34 is an important milestone on the trail to the next release,
> but we are not there yet.
>
> For example, the CMake test that is automatically produced every night
> by my computer for the CMake developers builds and tests the latest
> CMake.  One of those tests is the PLplot contract test which tests
> whether a build (but not test) of PLplot is successful.  That test is
> formally succeeding, but those PLplot builds are incomplete (with the
> cairo device driver dropped) because of incompatibilities with the way
> we configure our cairo device driver using internal details of the
> CMake pkg-config capability.  Although the use of such internal
> details has worked well over many years with few adjustments needed
> for changes to those internal details with CMake version, it is again
> no longer working with the very latest CMake.  This reflects the
> fundamental fragility of any method that uses internal details.
> Therefore, to deal with this issue my plan is to completely rewrite
> our support for the cairo device using the official CMake pkg-config
> support rather than internal details of that support.  And there are
> also a few other topics I would like to squeeze into the next release.
> So this makes the ETA of our next PLplot release still somewhat
> uncertain, but I am still hoping to get it done this year (before
> Christmas season) rather than early next year.
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Plplot now working well with Debian Buster + release timing

[Orion P. <or...@nw...>]

On 09/20/2018 12:22 AM, Alan W. Irwin wrote:
> On 2018-09-19 22:06-0600 Orion Poplawski wrote:
> 
>> On 09/15/2018 01:49 PM, Alan W. Irwin wrote:
>>> To Orion and Ole:
>>>
>>> Commit a730ebe34 has removed the last of the "new software" issues I
>>> have identified with Debian Testing = Buster.
>>>
>>> @Orion: I encourage you to try that commit on Fedora to see if you get
>>> similarly good results for all Linux-available components of
>>> PLplot for that other cutting-edge Linux platform.
>>>
>>> @Both: You both also might want to experiment with this commit as the
>>> basis for much-improved PLplot packages for Fedora and Debian.
>>> However such packages can only be considered preliminary until PLplot
>>> makes an official release.  What I can say on that topic is commit
>>> a730ebe34 is an important milestone on the trail to the next release,
>>> but we are not there yet.
>>>
>>> For example, the CMake test that is automatically produced every night
>>> by my computer for the CMake developers builds and tests the latest
>>> CMake.  One of those tests is the PLplot contract test which tests
>>> whether a build (but not test) of PLplot is successful.  That test is
>>> formally succeeding, but those PLplot builds are incomplete (with the
>>> cairo device driver dropped) because of incompatibilities with the way
>>> we configure our cairo device driver using internal details of the
>>> CMake pkg-config capability.  Although the use of such internal
>>> details has worked well over many years with few adjustments needed
>>> for changes to those internal details with CMake version, it is again
>>> no longer working with the very latest CMake.  This reflects the
>>> fundamental fragility of any method that uses internal details.
>>> Therefore, to deal with this issue my plan is to completely rewrite
>>> our support for the cairo device using the official CMake pkg-config
>>> support rather than internal details of that support.  And there are
>>> also a few other topics I would like to squeeze into the next release.
>>> So this makes the ETA of our next PLplot release still somewhat
>>> uncertain, but I am still hoping to get it done this year (before
>>> Christmas season) rather than early next year.
>>
>> Latest git (a9d9500c) built on Fedora Rawhide:
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905
>>
>> Despite the overall failure to build, looks mostly okay, but it 
>> appears that you don't support lua 5.3:
>>
>> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
>> version "5.2")
>> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
>> version "5.1")
>> -- LUA_INCLUDE_DIR =
>> -- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so
>> -- WARNING: Lua header and/or library not found. Disabling Lua binding
> 
> Hi Orion:
> 
> Thanks for that feedback.  Lua5.3 worked here (Debian Testing = Buster)
> for all but one example, but that one example exposed a Lua-5.3 bug
> (at least for the Debian version of Lua5.3) that was severe
> (arithmetic quit working if more than 8 (!) arrays were initialized).
> See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for a
> simple Lua script that triggers this Lua-5.3 bug and other details
> about this bug.  I temporarily worked around the problem by using our
> build system to blacklist Lua-5.3 until this bug is fixed (i.e.,
> in the absence of Lua5.1 or 5.2 our build system should just
> cleanly drop the Lua PLplot component and continue).
> 
> Please try that simple Lua script to see whether the Fedora version of
> Lua-5.3 also has this severe bug.  If you do confirm, then that is
> pretty good evidence it is a general Lua-5.3 bug (rather than just
> Debian related), and in this case I would be willing to take this
> issue to the Lua developers rather than waiting for some response to
> my bug report from the Debian packagers.
> 
> It appears from
> <https://kojipkgs.fedoraproject.org//work/tasks/1906/29771906/build.log>
> the blacklisting worked without actual build issues (as expected), but
> the actual error you get is because your rpm logic is expecting Lua
> files from PLplot that are not there because of the blacklisting.  So
> your response to this issue likely depends on whether you can get the
> above simple test script to work for Fedora's version of Lua5.3.  If
> that test actually works for Fedora, then it appears the Lua5.3 issue
> is simply a Debian packaging issue that has nothing to do with Fedora,
> and you should edit cmake/modules/lua.cmake to make the slight change
> to look first for 5.3, then 5.2, then 5.1.  However, if that test also
> fails for you, and you think the upstream Lua5.3 fix is going to take
> a while to get fixed, then you should change your rpm logic to drop
> all the expected Lua results.
> 
> Alan

I replied to the debian bug.  It appears that lua 5.3.5 on Fedora 
rawhide is fine.


-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Plplot-devel] Plplot now working well with Debian Buster + release timing

[Alan W. I. <Ala...@gm...>]

On 2018-09-20 21:09-0600 Orion Poplawski wrote:

> On 09/20/2018 12:22 AM, Alan W. Irwin wrote:
>> On 2018-09-19 22:06-0600 Orion Poplawski wrote:
>> 
>>> On 09/15/2018 01:49 PM, Alan W. Irwin wrote:
>>>> To Orion and Ole:
>>>> 
>>>> Commit a730ebe34 has removed the last of the "new software" issues I
>>>> have identified with Debian Testing = Buster.
>>>> 
>>>> @Orion: I encourage you to try that commit on Fedora to see if you get
>>>> similarly good results for all Linux-available components of
>>>> PLplot for that other cutting-edge Linux platform.
>>>> 
>>>> @Both: You both also might want to experiment with this commit as the
>>>> basis for much-improved PLplot packages for Fedora and Debian.
>>>> However such packages can only be considered preliminary until PLplot
>>>> makes an official release.  What I can say on that topic is commit
>>>> a730ebe34 is an important milestone on the trail to the next release,
>>>> but we are not there yet.
>>>> 
>>>> For example, the CMake test that is automatically produced every night
>>>> by my computer for the CMake developers builds and tests the latest
>>>> CMake.  One of those tests is the PLplot contract test which tests
>>>> whether a build (but not test) of PLplot is successful.  That test is
>>>> formally succeeding, but those PLplot builds are incomplete (with the
>>>> cairo device driver dropped) because of incompatibilities with the way
>>>> we configure our cairo device driver using internal details of the
>>>> CMake pkg-config capability.  Although the use of such internal
>>>> details has worked well over many years with few adjustments needed
>>>> for changes to those internal details with CMake version, it is again
>>>> no longer working with the very latest CMake.  This reflects the
>>>> fundamental fragility of any method that uses internal details.
>>>> Therefore, to deal with this issue my plan is to completely rewrite
>>>> our support for the cairo device using the official CMake pkg-config
>>>> support rather than internal details of that support.  And there are
>>>> also a few other topics I would like to squeeze into the next release.
>>>> So this makes the ETA of our next PLplot release still somewhat
>>>> uncertain, but I am still hoping to get it done this year (before
>>>> Christmas season) rather than early next year.
>>> 
>>> Latest git (a9d9500c) built on Fedora Rawhide:
>>> 
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905
>>> 
>>> Despite the overall failure to build, looks mostly okay, but it appears 
>>> that you don't support lua 5.3:
>>> 
>>> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
>>> version "5.2")
>>> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
>>> version "5.1")
>>> -- LUA_INCLUDE_DIR =
>>> -- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so
>>> -- WARNING: Lua header and/or library not found. Disabling Lua binding
>> 
>> Hi Orion:
>> 
>> Thanks for that feedback.  Lua5.3 worked here (Debian Testing = Buster)
>> for all but one example, but that one example exposed a Lua-5.3 bug
>> (at least for the Debian version of Lua5.3) that was severe
>> (arithmetic quit working if more than 8 (!) arrays were initialized).
>> See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for a
>> simple Lua script that triggers this Lua-5.3 bug and other details
>> about this bug.  I temporarily worked around the problem by using our
>> build system to blacklist Lua-5.3 until this bug is fixed (i.e.,
>> in the absence of Lua5.1 or 5.2 our build system should just
>> cleanly drop the Lua PLplot component and continue).
>> 
>> Please try that simple Lua script to see whether the Fedora version of
>> Lua-5.3 also has this severe bug.  If you do confirm, then that is
>> pretty good evidence it is a general Lua-5.3 bug (rather than just
>> Debian related), and in this case I would be willing to take this
>> issue to the Lua developers rather than waiting for some response to
>> my bug report from the Debian packagers.
>> 
>> It appears from
>> <https://kojipkgs.fedoraproject.org//work/tasks/1906/29771906/build.log>
>> the blacklisting worked without actual build issues (as expected), but
>> the actual error you get is because your rpm logic is expecting Lua
>> files from PLplot that are not there because of the blacklisting.  So
>> your response to this issue likely depends on whether you can get the
>> above simple test script to work for Fedora's version of Lua5.3.  If
>> that test actually works for Fedora, then it appears the Lua5.3 issue
>> is simply a Debian packaging issue that has nothing to do with Fedora,
>> and you should edit cmake/modules/lua.cmake to make the slight change
>> to look first for 5.3, then 5.2, then 5.1.  However, if that test also
>> fails for you, and you think the upstream Lua5.3 fix is going to take
>> a while to get fixed, then you should change your rpm logic to drop
>> all the expected Lua results.
>> 
>> Alan
>
> I replied to the debian bug.  It appears that lua 5.3.5 on Fedora rawhide is 
> fine.

See my further traffic there.

In any case I was coming around to the view that our build system
should not blacklist Lua5.3 since the issue I observe is a run-time
issue, i.e., it does not affect builds or generation of a binary deb
or rpm.  But now this conclusion is even stronger when it appears from
your Fedora results it is fairly likely the run-time issue is confined
just to Debian.

Therefore I have changed (see commit caf4801df) the Lua find logic so
if the user requests a certain version of Lua our build system will
attempt to find it, but otherwise the latest installed version of Lua
will be found.

Please try building an RPM again using this commit.

Alan
__________________________
Alan W. Irwin

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-devel] Plplot now working well with Debian Buster + release timing

[Alan W. I. <Ala...@gm...>]

Hi Ole:

I have just now updated PLplot (commit d2d9461a3) to allow our build
system to use local builds of Lua in a consistent fashion, and using
that capability I have proved the Debian Lua-5.3.3 issue is in
upstream 5.3.3 which is fixed in upstream 5.3.5 (see the latest
discussion at
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for more
details).

Furthermore, if you look at <https://tracker.debian.org/pkg/lua5.3>
the official maintainer has been inactive for the last three years so
others have been occasionally contributing with the last such activity
a year ago.  Therefore, would you be willing to do a NMU of lua-5.3.5
to allow the upstream fix for the lua issue I have been discussing to
propagate to Debian?  Such propagation should simplify your life
as the Debian maintainer for PLplot as well as being a big help
to each Debian user who is encountering this severe issue with Lua-5.3.3.

Alan
__________________________
Alan W. Irwin

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-devel] Cannot compile plplot using VS 2017

[Laurent B. <lau...@un...>]

Hi,

I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d

and delete cmakecache.txt and I I'm trying to build plplot in static

BUILD_SHARED_LIBS:BOOL=OFF

and ENABLE_DYNDRIVERS:BOOL=OFF

and I have got 59 errors compiling wxwidgets_dev.cpp.

In git repo I can find this file 
https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp

I copy 
https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36 
and insert those lines here 
https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41

I can compile and link plplot.




Errors list compiling wxwidgets_dev.cpp:

1>wxwidgets_dev.cpp
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(103): warning C4005: 
'AF_IPX': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(457): note: see previous 
definition of 'AF_IPX'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(147): warning C4005: 
'AF_MAX': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(476): note: see previous 
definition of 'AF_MAX'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(185): warning C4005: 
'SO_DONTLINGER': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(399): note: see previous 
definition of 'SO_DONTLINGER'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(235): error C2011: 
'sockaddr': 'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1007): note: see declaration 
of 'sockaddr'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(437): error C2059: syntax 
error: 'constant'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(437): error C3805: 
'constant': unexpected token, expected either '}' or a ','
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(572): warning C4005: 
'IN_CLASSA': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(284): note: see previous 
definition of 'IN_CLASSA'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(578): warning C4005: 
'IN_CLASSB': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(290): note: see previous 
definition of 'IN_CLASSB'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(584): warning C4005: 
'IN_CLASSC': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(296): note: see previous 
definition of 'IN_CLASSC'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(595): warning C4005: 
'INADDR_ANY': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(301): note: see previous 
definition of 'INADDR_ANY'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(597): warning C4005: 
'INADDR_BROADCAST': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(303): note: see previous 
definition of 'INADDR_BROADCAST'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(633): error C2011: 
'sockaddr_in': 'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1011): note: see declaration 
of 'sockaddr_in'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(136): error C2011: 'fd_set': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1019): note: see declaration 
of 'fd_set'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(156): warning C4005: 
'FD_CLR': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(94): note: see previous 
definition of 'FD_CLR'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(171): warning C4005: 
'FD_SET': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(99): note: see previous 
definition of 'FD_SET'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(180): error C2011: 'timeval': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1035): note: see declaration 
of 'timeval'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(236): error C2011: 'hostent': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1023): note: see declaration 
of 'hostent'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(249): error C2011: 'netent': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(177): note: see declaration of 
'netent'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(256): error C2011: 'servent': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1027): note: see declaration 
of 'servent'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(268): error C2011: 
'protoent': 'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1031): note: see declaration 
of 'protoent'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(364): error C2011: 'WSAData': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(319): note: see declaration of 
'WSAData'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(462): error C2011: 
'sockproto': 'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(491): note: see declaration of 
'sockproto'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(504): error C2011: 'linger': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1015): note: see declaration 
of 'linger'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(517): warning C4005: 
'SOMAXCONN': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(541): note: see previous 
definition of 'SOMAXCONN'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(551): warning C4005: 
'FD_READ': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(559): note: see previous 
definition of 'FD_READ'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(554): warning C4005: 
'FD_WRITE': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(560): note: see previous 
definition of 'FD_WRITE'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(557): warning C4005: 
'FD_OOB': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(561): note: see previous 
definition of 'FD_OOB'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(560): warning C4005: 
'FD_ACCEPT': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(562): note: see previous 
definition of 'FD_ACCEPT'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(563): warning C4005: 
'FD_CONNECT': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(563): note: see previous 
definition of 'FD_CONNECT'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(566): warning C4005: 
'FD_CLOSE': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(564): note: see previous 
definition of 'FD_CLOSE'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1624): error C2375: 'accept': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(739): note: see declaration of 
'accept'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1646): error C2375: 'bind': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(744): note: see declaration of 
'bind'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1667): error C2375: 
'closesocket': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(749): note: see declaration of 
'closesocket'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1684): error C2375: 
'connect': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(751): note: see declaration of 
'connect'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1705): error C2375: 
'ioctlsocket': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(756): note: see declaration of 
'ioctlsocket'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1728): error C2375: 
'getpeername': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(761): note: see declaration of 
'getpeername'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1749): error C2375: 
'getsockname': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(766): note: see declaration of 
'getsockname'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1770): error C2375: 
'getsockopt': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(771): note: see declaration of 
'getsockopt'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1795): error C2375: 'htonl': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(778): note: see declaration of 
'htonl'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1812): error C2375: 'htons': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(780): note: see declaration of 
'htons'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1830): error C2375: 
'inet_addr': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(782): note: see declaration of 
'inet_addr'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1848): error C2375: 
'inet_ntoa': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(784): note: see declaration of 
'inet_ntoa'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1948): error C2375: 'listen': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(786): note: see declaration of 
'listen'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1967): error C2375: 'ntohl': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(790): note: see declaration of 
'ntohl'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1984): error C2375: 'ntohs': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(792): note: see declaration of 
'ntohs'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2001): error C2375: 'recv': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(794): note: see declaration of 
'recv'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2024): error C2375: 
'recvfrom': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(800): note: see declaration of 
'recvfrom'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2051): error C2375: 'select': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(808): note: see declaration of 
'select'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2076): error C2375: 'send': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(815): note: see declaration of 
'send'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2099): error C2375: 'sendto': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(821): note: see declaration of 
'sendto'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2126): error C2375: 
'setsockopt': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(829): note: see declaration of 
'setsockopt'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2151): error C2375: 
'shutdown': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(836): note: see declaration of 
'shutdown'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2171): error C2375: 'socket': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(840): note: see declaration of 
'socket'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2196): error C2375: 
'gethostbyaddr': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(847): note: see declaration of 
'gethostbyaddr'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2218): error C2375: 
'gethostbyname': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(852): note: see declaration of 
'gethostbyname'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2235): error C2375: 
'gethostname': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(854): note: see declaration of 
'gethostname'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2275): error C2375: 
'getservbyport': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(858): note: see declaration of 
'getservbyport'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2294): error C2375: 
'getservbyname': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(862): note: see declaration of 
'getservbyname'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2313): error C2375: 
'getprotobynumber': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(866): note: see declaration of 
'getprotobynumber'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2330): error C2375: 
'getprotobyname': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(868): note: see declaration of 
'getprotobyname'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2350): error C2375: 
'WSAStartup': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(872): note: see declaration of 
'WSAStartup'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2370): error C2375: 
'WSACleanup': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(876): note: see declaration of 
'WSACleanup'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2387): error C2375: 
'WSASetLastError': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(878): note: see declaration of 
'WSASetLastError'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2404): error C2375: 
'WSAGetLastError': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(880): note: see declaration of 
'WSAGetLastError'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2425): error C2375: 
'WSAIsBlocking': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(882): note: see declaration of 
'WSAIsBlocking'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2443): error C2375: 
'WSAUnhookBlockingHook': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(884): note: see declaration of 
'WSAUnhookBlockingHook'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2461): error C2375: 
'WSASetBlockingHook': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(886): note: see declaration of 
'WSASetBlockingHook'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2479): error C2375: 
'WSACancelBlockingCall': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(888): note: see declaration of 
'WSACancelBlockingCall'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2497): error C2375: 
'WSAAsyncGetServByName': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(890): note: see declaration of 
'WSAAsyncGetServByName'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2525): error C2375: 
'WSAAsyncGetServByPort': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(898): note: see declaration of 
'WSAAsyncGetServByPort'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2553): error C2375: 
'WSAAsyncGetProtoByName': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(906): note: see declaration of 
'WSAAsyncGetProtoByName'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2579): error C2375: 
'WSAAsyncGetProtoByNumber': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(913): note: see declaration of 
'WSAAsyncGetProtoByNumber'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2605): error C2375: 
'WSAAsyncGetHostByName': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(920): note: see declaration of 
'WSAAsyncGetHostByName'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2631): error C2375: 
'WSAAsyncGetHostByAddr': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(927): note: see declaration of 
'WSAAsyncGetHostByAddr'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2661): error C2375: 
'WSACancelAsyncRequest': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(936): note: see declaration of 
'WSACancelAsyncRequest'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2679): error C2375: 
'WSAAsyncSelect': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(938): note: see declaration of 
'WSAAsyncSelect'
1>g:\lib\plplot\drivers\wxwidgets_dev.cpp(736): warning C4996: 
'wxFont::wxFont': deprecated: use wxFONT{FAMILY,STYLE,WEIGHT}_XXX 
constants ie: wxFONTFAMILY_SWISS, wxFONTSTYLE_NORMAL, wxFONTWEIGHT_BOLD
1>g:\lib\install\wxwidgets\include\wx\msw\font.h(115): note: see 
declaration of 'wxFont::wxFont'
1>g:\lib\plplot\drivers\wxwidgets_dev.cpp(1010): warning C4996: 
'wxPen::wxPen': deprecated: use wxPENSTYLE_XXX constants
1>g:\lib\install\wxwidgets\include\wx\msw\pen.h(58): note: see 
declaration of 'wxPen::wxPen'
1>g:\lib\plplot\drivers\wxwidgets_dev.cpp(1045): warning C4996: 
'wxPen::wxPen': deprecated: use wxPENSTYLE_XXX constants
1>g:\lib\install\wxwidgets\include\wx\msw\pen.h(58): note: see 
declaration of 'wxPen::wxPen'
1>g:\lib\plplot\drivers\wxwidgets_dev.cpp(1058): warning C4996: 
'wxPen::wxPen': deprecated: use wxPENSTYLE_XXX constants
1>g:\lib\install\wxwidgets\include\wx\msw\pen.h(58): note: see 
declaration of 'wxPen::wxPen'
1>Done building project "plplot.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(235): error C2011: 
'sockaddr': 'struct' type redefinition





Configuration

Cmake 3.11.0

VS 2017 win 64 Version 15.6.3

wxwidgets 3.1.2


Le 21/09/2018 à 05:09, Orion Poplawski a écrit :
> On 09/20/2018 12:22 AM, Alan W. Irwin wrote:
>> On 2018-09-19 22:06-0600 Orion Poplawski wrote:
>>
>>> On 09/15/2018 01:49 PM, Alan W. Irwin wrote:
>>>> To Orion and Ole:
>>>>
>>>> Commit a730ebe34 has removed the last of the "new software" issues I
>>>> have identified with Debian Testing = Buster.
>>>>
>>>> @Orion: I encourage you to try that commit on Fedora to see if you get
>>>> similarly good results for all Linux-available components of
>>>> PLplot for that other cutting-edge Linux platform.
>>>>
>>>> @Both: You both also might want to experiment with this commit as the
>>>> basis for much-improved PLplot packages for Fedora and Debian.
>>>> However such packages can only be considered preliminary until PLplot
>>>> makes an official release.  What I can say on that topic is commit
>>>> a730ebe34 is an important milestone on the trail to the next release,
>>>> but we are not there yet.
>>>>
>>>> For example, the CMake test that is automatically produced every night
>>>> by my computer for the CMake developers builds and tests the latest
>>>> CMake.  One of those tests is the PLplot contract test which tests
>>>> whether a build (but not test) of PLplot is successful. That test is
>>>> formally succeeding, but those PLplot builds are incomplete (with the
>>>> cairo device driver dropped) because of incompatibilities with the way
>>>> we configure our cairo device driver using internal details of the
>>>> CMake pkg-config capability.  Although the use of such internal
>>>> details has worked well over many years with few adjustments needed
>>>> for changes to those internal details with CMake version, it is again
>>>> no longer working with the very latest CMake.  This reflects the
>>>> fundamental fragility of any method that uses internal details.
>>>> Therefore, to deal with this issue my plan is to completely rewrite
>>>> our support for the cairo device using the official CMake pkg-config
>>>> support rather than internal details of that support.  And there are
>>>> also a few other topics I would like to squeeze into the next release.
>>>> So this makes the ETA of our next PLplot release still somewhat
>>>> uncertain, but I am still hoping to get it done this year (before
>>>> Christmas season) rather than early next year.
>>>
>>> Latest git (a9d9500c) built on Fedora Rawhide:
>>>
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905
>>>
>>> Despite the overall failure to build, looks mostly okay, but it 
>>> appears that you don't support lua 5.3:
>>>
>>> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
>>> version "5.2")
>>> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
>>> version "5.1")
>>> -- LUA_INCLUDE_DIR =
>>> -- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so
>>> -- WARNING: Lua header and/or library not found. Disabling Lua binding
>>
>> Hi Orion:
>>
>> Thanks for that feedback.  Lua5.3 worked here (Debian Testing = Buster)
>> for all but one example, but that one example exposed a Lua-5.3 bug
>> (at least for the Debian version of Lua5.3) that was severe
>> (arithmetic quit working if more than 8 (!) arrays were initialized).
>> See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for a
>> simple Lua script that triggers this Lua-5.3 bug and other details
>> about this bug.  I temporarily worked around the problem by using our
>> build system to blacklist Lua-5.3 until this bug is fixed (i.e.,
>> in the absence of Lua5.1 or 5.2 our build system should just
>> cleanly drop the Lua PLplot component and continue).
>>
>> Please try that simple Lua script to see whether the Fedora version of
>> Lua-5.3 also has this severe bug.  If you do confirm, then that is
>> pretty good evidence it is a general Lua-5.3 bug (rather than just
>> Debian related), and in this case I would be willing to take this
>> issue to the Lua developers rather than waiting for some response to
>> my bug report from the Debian packagers.
>>
>> It appears from
>> <https://kojipkgs.fedoraproject.org//work/tasks/1906/29771906/build.log>
>> the blacklisting worked without actual build issues (as expected), but
>> the actual error you get is because your rpm logic is expecting Lua
>> files from PLplot that are not there because of the blacklisting.  So
>> your response to this issue likely depends on whether you can get the
>> above simple test script to work for Fedora's version of Lua5.3.  If
>> that test actually works for Fedora, then it appears the Lua5.3 issue
>> is simply a Debian packaging issue that has nothing to do with Fedora,
>> and you should edit cmake/modules/lua.cmake to make the slight change
>> to look first for 5.3, then 5.2, then 5.1.  However, if that test also
>> fails for you, and you think the upstream Lua5.3 fix is going to take
>> a while to get fixed, then you should change your rpm logic to drop
>> all the expected Lua results.
>>
>> Alan
>
> I replied to the debian bug.  It appears that lua 5.3.5 on Fedora 
> rawhide is fine.
>
>

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Alan W. I. <Ala...@gm...>]

On 2018-09-21 18:38+0200 Laurent Berger wrote:

> Hi,
>
> I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
> ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
>
> and delete cmakecache.txt and I I'm trying to build plplot in static
>
> BUILD_SHARED_LIBS:BOOL=OFF
>
> and ENABLE_DYNDRIVERS:BOOL=OFF
>
> and I have got 59 errors compiling wxwidgets_dev.cpp.
>
> In git repo I can find this file 
> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
>
> I copy 
> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36 
> and insert those lines here 
> https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
>
> I can compile and link plplot.

Hi Laurent:

Thanks for your test of my recent PLplot development activity.

I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
and caf4801dfe (current master tip), and your description of the
required change appears to correspond to copying some wxwidgets includes from
one part of the old commit (or alternatively the latest commit since
those lines haven't changed) to just after

#include "wxwidgets.h"

As far as I can tell such a copy of includes should have zero effect
so it appears either I misunderstood the change you described above or
else the github repo for PLplot is not properly up to date with the
definitive SourceForge repo.  So to remove this uncertainty please
give us the results of

git diff

to describe the definitive version of the change to the master tip of
PLplot that works for you (i.e., allows a static build of PLplot to
compile and link for your VS2017 platform).

By the way, a comprehensive test of PLplot has recently (one commit
behind master tip) worked perfectly here on Linux (Debian Buster).
Such comprehensive tests include not only building a static wxwidgets
device but run-time testing it as well.  Also that last commit on the
master branch is a minor one involving how to control the Lua version
that is searched for and is therefore extremely unlikely to introduce
wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
so someone with access to recent Windows platforms will have to
attempt that instead.

Alan
__________________________
Alan W. Irwin

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-devel] Cannot compile plplot using VS 2017

[Phil R. <p.d...@gm...>]

Hi Laurent
What a strange set of compilation errors. They are all from windows
sockets headers, rather than from wxWidgets.

Here is my guess at what is happening - but I have not been able to
reproduce the error (I am using VS 2015 still).

In the code before your edits following the #includes through, it
turns out we include <windows.h> into wxwidgets_dev.cpp before any
wxWidgets headers. This is done via "wxwidgets.h", then
"wxwidgets_comms.h". The winsock related functions probably get pulled
in via windows.h. I have a feeling that one of the wx headers is then
pulling in alternate definitions of those winsock functions, but I'm
not sure from where.

By shuffling the headers round as you have, you include <wx/wx.h>
before we pull in <windows.h>. The <wx/wx.h> file will in turn pull in
<windows.h> itself. then our include windows.h should get ignored.

I can't think how exectly it might work, but I bet there is some weird
inconsistency between how <windows.h> is pulled in by us, vs how it is
pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
or extern "C".

Anyway I might guess that moving the headers around is simply masking
some other problem. Can I check that you have built wxWidgets with the
same virsion of visual studio? And that it is also built as a static
lib? Just a hunch but maybe something to do with the wxwidgets library
configuration is causing the issue.

Phil
On Fri, 21 Sep 2018 at 23:08, Alan W. Irwin <Ala...@gm...> wrote:
>
> On 2018-09-21 18:38+0200 Laurent Berger wrote:
>
> > Hi,
> >
> > I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
> > ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
> >
> > and delete cmakecache.txt and I I'm trying to build plplot in static
> >
> > BUILD_SHARED_LIBS:BOOL=OFF
> >
> > and ENABLE_DYNDRIVERS:BOOL=OFF
> >
> > and I have got 59 errors compiling wxwidgets_dev.cpp.
> >
> > In git repo I can find this file
> > https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
> >
> > I copy
> > https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36
> > and insert those lines here
> > https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
> >
> > I can compile and link plplot.
>
> Hi Laurent:
>
> Thanks for your test of my recent PLplot development activity.
>
> I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
> and caf4801dfe (current master tip), and your description of the
> required change appears to correspond to copying some wxwidgets includes from
> one part of the old commit (or alternatively the latest commit since
> those lines haven't changed) to just after
>
> #include "wxwidgets.h"
>
> As far as I can tell such a copy of includes should have zero effect
> so it appears either I misunderstood the change you described above or
> else the github repo for PLplot is not properly up to date with the
> definitive SourceForge repo.  So to remove this uncertainty please
> give us the results of
>
> git diff
>
> to describe the definitive version of the change to the master tip of
> PLplot that works for you (i.e., allows a static build of PLplot to
> compile and link for your VS2017 platform).
>
> By the way, a comprehensive test of PLplot has recently (one commit
> behind master tip) worked perfectly here on Linux (Debian Buster).
> Such comprehensive tests include not only building a static wxwidgets
> device but run-time testing it as well.  Also that last commit on the
> master branch is a minor one involving how to control the Lua version
> that is searched for and is therefore extremely unlikely to introduce
> wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
> so someone with access to recent Windows platforms will have to
> attempt that instead.
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Laurent B. <lau...@un...>]

Hi Phil, Alan,

I check everything this morning (local time) and I have got same errors.

I attached my cmakecache for plplot and cmakecache for wxwidgets

git diff

Laurent@PC-Laurent-Vision MINGW64 /g/lib/plplot (master)
$ git diff
diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
index 6351c6893..27b20750e 100644
--- a/drivers/wxwidgets_dev.cpp
+++ b/drivers/wxwidgets_dev.cpp
@@ -38,7 +38,15 @@
  #else
  #include <fstream>
  #endif
+#include <wx/wx.h>
+#include <wx/wfstream.h>
+#include <wx/except.h>

+#include "plDevs.h"
+
+// plplot headers
+#include "plplotP.h"
+#include "drivers.h"
  // PLplot headers
  #include "plDevs.h"
  #include "wxwidgets.h" // includes wx/wx.h




Le 22/09/2018 à 01:37, Phil Rosenberg a écrit :
> Hi Laurent
> What a strange set of compilation errors. They are all from windows
> sockets headers, rather than from wxWidgets.
>
> Here is my guess at what is happening - but I have not been able to
> reproduce the error (I am using VS 2015 still).
>
> In the code before your edits following the #includes through, it
> turns out we include <windows.h> into wxwidgets_dev.cpp before any
> wxWidgets headers. This is done via "wxwidgets.h", then
> "wxwidgets_comms.h". The winsock related functions probably get pulled
> in via windows.h. I have a feeling that one of the wx headers is then
> pulling in alternate definitions of those winsock functions, but I'm
> not sure from where.
>
> By shuffling the headers round as you have, you include <wx/wx.h>
> before we pull in <windows.h>. The <wx/wx.h> file will in turn pull in
> <windows.h> itself. then our include windows.h should get ignored.
>
> I can't think how exectly it might work, but I bet there is some weird
> inconsistency between how <windows.h> is pulled in by us, vs how it is
> pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
> or extern "C".
>
> Anyway I might guess that moving the headers around is simply masking
> some other problem. Can I check that you have built wxWidgets with the
> same virsion of visual studio? And that it is also built as a static
> lib? Just a hunch but maybe something to do with the wxwidgets library
> configuration is causing the issue.
>
> Phil
> On Fri, 21 Sep 2018 at 23:08, Alan W. Irwin <Ala...@gm...> wrote:
>> On 2018-09-21 18:38+0200 Laurent Berger wrote:
>>
>>> Hi,
>>>
>>> I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
>>> ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
>>>
>>> and delete cmakecache.txt and I I'm trying to build plplot in static
>>>
>>> BUILD_SHARED_LIBS:BOOL=OFF
>>>
>>> and ENABLE_DYNDRIVERS:BOOL=OFF
>>>
>>> and I have got 59 errors compiling wxwidgets_dev.cpp.
>>>
>>> In git repo I can find this file
>>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
>>>
>>> I copy
>>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36
>>> and insert those lines here
>>> https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
>>>
>>> I can compile and link plplot.
>> Hi Laurent:
>>
>> Thanks for your test of my recent PLplot development activity.
>>
>> I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
>> and caf4801dfe (current master tip), and your description of the
>> required change appears to correspond to copying some wxwidgets includes from
>> one part of the old commit (or alternatively the latest commit since
>> those lines haven't changed) to just after
>>
>> #include "wxwidgets.h"
>>
>> As far as I can tell such a copy of includes should have zero effect
>> so it appears either I misunderstood the change you described above or
>> else the github repo for PLplot is not properly up to date with the
>> definitive SourceForge repo.  So to remove this uncertainty please
>> give us the results of
>>
>> git diff
>>
>> to describe the definitive version of the change to the master tip of
>> PLplot that works for you (i.e., allows a static build of PLplot to
>> compile and link for your VS2017 platform).
>>
>> By the way, a comprehensive test of PLplot has recently (one commit
>> behind master tip) worked perfectly here on Linux (Debian Buster).
>> Such comprehensive tests include not only building a static wxwidgets
>> device but run-time testing it as well.  Also that last commit on the
>> master branch is a minor one involving how to control the Lua version
>> that is searched for and is therefore extremely unlikely to introduce
>> wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
>> so someone with access to recent Windows platforms will have to
>> attempt that instead.
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> 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-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Phil R. <p.d...@gm...>]

Hi Laurent

Okay, well if your solution works, the I think we should add it in.

Could I please ask for you to check what the minimum list of headers
to be included needs to be? Would just adding wx/wx.h be sufficient or
do all those headers need to be added?

Phil

Phil
On Sat, 22 Sep 2018 at 10:24, Laurent Berger
<lau...@un...> wrote:
>
> Hi Phil, Alan,
>
> I check everything this morning (local time) and I have got same errors.
>
> I attached my cmakecache for plplot and cmakecache for wxwidgets
>
> git diff
>
> Laurent@PC-Laurent-Vision MINGW64 /g/lib/plplot (master)
> $ git diff
> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
> index 6351c6893..27b20750e 100644
> --- a/drivers/wxwidgets_dev.cpp
> +++ b/drivers/wxwidgets_dev.cpp
> @@ -38,7 +38,15 @@
>   #else
>   #include <fstream>
>   #endif
> +#include <wx/wx.h>
> +#include <wx/wfstream.h>
> +#include <wx/except.h>
>
> +#include "plDevs.h"
> +
> +// plplot headers
> +#include "plplotP.h"
> +#include "drivers.h"
>   // PLplot headers
>   #include "plDevs.h"
>   #include "wxwidgets.h" // includes wx/wx.h
>
>
>
>
> Le 22/09/2018 à 01:37, Phil Rosenberg a écrit :
> > Hi Laurent
> > What a strange set of compilation errors. They are all from windows
> > sockets headers, rather than from wxWidgets.
> >
> > Here is my guess at what is happening - but I have not been able to
> > reproduce the error (I am using VS 2015 still).
> >
> > In the code before your edits following the #includes through, it
> > turns out we include <windows.h> into wxwidgets_dev.cpp before any
> > wxWidgets headers. This is done via "wxwidgets.h", then
> > "wxwidgets_comms.h". The winsock related functions probably get pulled
> > in via windows.h. I have a feeling that one of the wx headers is then
> > pulling in alternate definitions of those winsock functions, but I'm
> > not sure from where.
> >
> > By shuffling the headers round as you have, you include <wx/wx.h>
> > before we pull in <windows.h>. The <wx/wx.h> file will in turn pull in
> > <windows.h> itself. then our include windows.h should get ignored.
> >
> > I can't think how exectly it might work, but I bet there is some weird
> > inconsistency between how <windows.h> is pulled in by us, vs how it is
> > pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
> > or extern "C".
> >
> > Anyway I might guess that moving the headers around is simply masking
> > some other problem. Can I check that you have built wxWidgets with the
> > same virsion of visual studio? And that it is also built as a static
> > lib? Just a hunch but maybe something to do with the wxwidgets library
> > configuration is causing the issue.
> >
> > Phil
> > On Fri, 21 Sep 2018 at 23:08, Alan W. Irwin <Ala...@gm...> wrote:
> >> On 2018-09-21 18:38+0200 Laurent Berger wrote:
> >>
> >>> Hi,
> >>>
> >>> I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
> >>> ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
> >>>
> >>> and delete cmakecache.txt and I I'm trying to build plplot in static
> >>>
> >>> BUILD_SHARED_LIBS:BOOL=OFF
> >>>
> >>> and ENABLE_DYNDRIVERS:BOOL=OFF
> >>>
> >>> and I have got 59 errors compiling wxwidgets_dev.cpp.
> >>>
> >>> In git repo I can find this file
> >>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
> >>>
> >>> I copy
> >>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36
> >>> and insert those lines here
> >>> https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
> >>>
> >>> I can compile and link plplot.
> >> Hi Laurent:
> >>
> >> Thanks for your test of my recent PLplot development activity.
> >>
> >> I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
> >> and caf4801dfe (current master tip), and your description of the
> >> required change appears to correspond to copying some wxwidgets includes from
> >> one part of the old commit (or alternatively the latest commit since
> >> those lines haven't changed) to just after
> >>
> >> #include "wxwidgets.h"
> >>
> >> As far as I can tell such a copy of includes should have zero effect
> >> so it appears either I misunderstood the change you described above or
> >> else the github repo for PLplot is not properly up to date with the
> >> definitive SourceForge repo.  So to remove this uncertainty please
> >> give us the results of
> >>
> >> git diff
> >>
> >> to describe the definitive version of the change to the master tip of
> >> PLplot that works for you (i.e., allows a static build of PLplot to
> >> compile and link for your VS2017 platform).
> >>
> >> By the way, a comprehensive test of PLplot has recently (one commit
> >> behind master tip) worked perfectly here on Linux (Debian Buster).
> >> Such comprehensive tests include not only building a static wxwidgets
> >> device but run-time testing it as well.  Also that last commit on the
> >> master branch is a minor one involving how to control the Lua version
> >> that is searched for and is therefore extremely unlikely to introduce
> >> wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
> >> so someone with access to recent Windows platforms will have to
> >> attempt that instead.
> >>
> >> Alan
> >> __________________________
> >> Alan W. Irwin
> >>
> >> 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-devel mailing list
> >> Plp...@li...
> >> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Laurent B. <lau...@un...>]

I tried  2 solutions :

FIRST solution

don't change wxwidgets_dev.cpp

and change include order in wxwidgets.h #include <wx/wx.h> after 
<memory> and before  // plplot headers

then  $ git diff is
diff --git a/drivers/wxwidgets.h b/drivers/wxwidgets.h
index 884292d07..0818f357c 100644
--- a/drivers/wxwidgets.h
+++ b/drivers/wxwidgets.h
@@ -22,13 +22,14 @@

  #include <vector>
  #include <memory>
+#include <wx/wx.h>

  // plplot headers
  #include "plplotP.h"
  #include "wxwidgets_comms.h"

  // some special wxWidgets headers
-#include <wx/wx.h>
+//#include <wx/wx.h>
  #include <wx/spinctrl.h>
  #include <wx/dcgraph.h>

SECOND solution

add #include <wx/wx.h> in wxwidgets_dev.cpp at line 41

then $git diff is
diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
index 6351c6893..07089d83a 100644
--- a/drivers/wxwidgets_dev.cpp
+++ b/drivers/wxwidgets_dev.cpp
@@ -38,7 +38,7 @@
  #else
  #include <fstream>
  #endif
-
+#include <wx/wx.h>
  // PLplot headers
  #include "plDevs.h"
  #include "wxwidgets.h" // includes wx/wx.h



Le 22/09/2018 à 12:26, Phil Rosenberg a écrit :
> Hi Laurent
>
> Okay, well if your solution works, the I think we should add it in.
>
> Could I please ask for you to check what the minimum list of headers
> to be included needs to be? Would just adding wx/wx.h be sufficient or
> do all those headers need to be added?
>
> Phil
>
> Phil
> On Sat, 22 Sep 2018 at 10:24, Laurent Berger
> <lau...@un...> wrote:
>> Hi Phil, Alan,
>>
>> I check everything this morning (local time) and I have got same errors.
>>
>> I attached my cmakecache for plplot and cmakecache for wxwidgets
>>
>> git diff
>>
>> Laurent@PC-Laurent-Vision MINGW64 /g/lib/plplot (master)
>> $ git diff
>> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
>> index 6351c6893..27b20750e 100644
>> --- a/drivers/wxwidgets_dev.cpp
>> +++ b/drivers/wxwidgets_dev.cpp
>> @@ -38,7 +38,15 @@
>>    #else
>>    #include <fstream>
>>    #endif
>> +#include <wx/wx.h>
>> +#include <wx/wfstream.h>
>> +#include <wx/except.h>
>>
>> +#include "plDevs.h"
>> +
>> +// plplot headers
>> +#include "plplotP.h"
>> +#include "drivers.h"
>>    // PLplot headers
>>    #include "plDevs.h"
>>    #include "wxwidgets.h" // includes wx/wx.h
>>
>>
>>
>>
>> Le 22/09/2018 à 01:37, Phil Rosenberg a écrit :
>>> Hi Laurent
>>> What a strange set of compilation errors. They are all from windows
>>> sockets headers, rather than from wxWidgets.
>>>
>>> Here is my guess at what is happening - but I have not been able to
>>> reproduce the error (I am using VS 2015 still).
>>>
>>> In the code before your edits following the #includes through, it
>>> turns out we include <windows.h> into wxwidgets_dev.cpp before any
>>> wxWidgets headers. This is done via "wxwidgets.h", then
>>> "wxwidgets_comms.h". The winsock related functions probably get pulled
>>> in via windows.h. I have a feeling that one of the wx headers is then
>>> pulling in alternate definitions of those winsock functions, but I'm
>>> not sure from where.
>>>
>>> By shuffling the headers round as you have, you include <wx/wx.h>
>>> before we pull in <windows.h>. The <wx/wx.h> file will in turn pull in
>>> <windows.h> itself. then our include windows.h should get ignored.
>>>
>>> I can't think how exectly it might work, but I bet there is some weird
>>> inconsistency between how <windows.h> is pulled in by us, vs how it is
>>> pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
>>> or extern "C".
>>>
>>> Anyway I might guess that moving the headers around is simply masking
>>> some other problem. Can I check that you have built wxWidgets with the
>>> same virsion of visual studio? And that it is also built as a static
>>> lib? Just a hunch but maybe something to do with the wxwidgets library
>>> configuration is causing the issue.
>>>
>>> Phil
>>> On Fri, 21 Sep 2018 at 23:08, Alan W. Irwin <Ala...@gm...> wrote:
>>>> On 2018-09-21 18:38+0200 Laurent Berger wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
>>>>> ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
>>>>>
>>>>> and delete cmakecache.txt and I I'm trying to build plplot in static
>>>>>
>>>>> BUILD_SHARED_LIBS:BOOL=OFF
>>>>>
>>>>> and ENABLE_DYNDRIVERS:BOOL=OFF
>>>>>
>>>>> and I have got 59 errors compiling wxwidgets_dev.cpp.
>>>>>
>>>>> In git repo I can find this file
>>>>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
>>>>>
>>>>> I copy
>>>>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36
>>>>> and insert those lines here
>>>>> https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
>>>>>
>>>>> I can compile and link plplot.
>>>> Hi Laurent:
>>>>
>>>> Thanks for your test of my recent PLplot development activity.
>>>>
>>>> I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
>>>> and caf4801dfe (current master tip), and your description of the
>>>> required change appears to correspond to copying some wxwidgets includes from
>>>> one part of the old commit (or alternatively the latest commit since
>>>> those lines haven't changed) to just after
>>>>
>>>> #include "wxwidgets.h"
>>>>
>>>> As far as I can tell such a copy of includes should have zero effect
>>>> so it appears either I misunderstood the change you described above or
>>>> else the github repo for PLplot is not properly up to date with the
>>>> definitive SourceForge repo.  So to remove this uncertainty please
>>>> give us the results of
>>>>
>>>> git diff
>>>>
>>>> to describe the definitive version of the change to the master tip of
>>>> PLplot that works for you (i.e., allows a static build of PLplot to
>>>> compile and link for your VS2017 platform).
>>>>
>>>> By the way, a comprehensive test of PLplot has recently (one commit
>>>> behind master tip) worked perfectly here on Linux (Debian Buster).
>>>> Such comprehensive tests include not only building a static wxwidgets
>>>> device but run-time testing it as well.  Also that last commit on the
>>>> master branch is a minor one involving how to control the Lua version
>>>> that is searched for and is therefore extremely unlikely to introduce
>>>> wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
>>>> so someone with access to recent Windows platforms will have to
>>>> attempt that instead.
>>>>
>>>> Alan
>>>> __________________________
>>>> Alan W. Irwin
>>>>
>>>> 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-devel mailing list
>>>> Plp...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Phil R. <p.d...@gm...>]

Hi Laurent

I have implemented your first solution. If you could let me know that
things now work for you that would be great.

Thanks

Phil
On Sat, 22 Sep 2018 at 11:44, Laurent Berger
<lau...@un...> wrote:
>
> I tried  2 solutions :
>
> FIRST solution
>
> don't change wxwidgets_dev.cpp
>
> and change include order in wxwidgets.h #include <wx/wx.h> after
> <memory> and before  // plplot headers
>
> then  $ git diff is
> diff --git a/drivers/wxwidgets.h b/drivers/wxwidgets.h
> index 884292d07..0818f357c 100644
> --- a/drivers/wxwidgets.h
> +++ b/drivers/wxwidgets.h
> @@ -22,13 +22,14 @@
>
>   #include <vector>
>   #include <memory>
> +#include <wx/wx.h>
>
>   // plplot headers
>   #include "plplotP.h"
>   #include "wxwidgets_comms.h"
>
>   // some special wxWidgets headers
> -#include <wx/wx.h>
> +//#include <wx/wx.h>
>   #include <wx/spinctrl.h>
>   #include <wx/dcgraph.h>
>
> SECOND solution
>
> add #include <wx/wx.h> in wxwidgets_dev.cpp at line 41
>
> then $git diff is
> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
> index 6351c6893..07089d83a 100644
> --- a/drivers/wxwidgets_dev.cpp
> +++ b/drivers/wxwidgets_dev.cpp
> @@ -38,7 +38,7 @@
>   #else
>   #include <fstream>
>   #endif
> -
> +#include <wx/wx.h>
>   // PLplot headers
>   #include "plDevs.h"
>   #include "wxwidgets.h" // includes wx/wx.h
>
>
>
> Le 22/09/2018 à 12:26, Phil Rosenberg a écrit :
> > Hi Laurent
> >
> > Okay, well if your solution works, the I think we should add it in.
> >
> > Could I please ask for you to check what the minimum list of headers
> > to be included needs to be? Would just adding wx/wx.h be sufficient or
> > do all those headers need to be added?
> >
> > Phil
> >
> > Phil
> > On Sat, 22 Sep 2018 at 10:24, Laurent Berger
> > <lau...@un...> wrote:
> >> Hi Phil, Alan,
> >>
> >> I check everything this morning (local time) and I have got same errors.
> >>
> >> I attached my cmakecache for plplot and cmakecache for wxwidgets
> >>
> >> git diff
> >>
> >> Laurent@PC-Laurent-Vision MINGW64 /g/lib/plplot (master)
> >> $ git diff
> >> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
> >> index 6351c6893..27b20750e 100644
> >> --- a/drivers/wxwidgets_dev.cpp
> >> +++ b/drivers/wxwidgets_dev.cpp
> >> @@ -38,7 +38,15 @@
> >>    #else
> >>    #include <fstream>
> >>    #endif
> >> +#include <wx/wx.h>
> >> +#include <wx/wfstream.h>
> >> +#include <wx/except.h>
> >>
> >> +#include "plDevs.h"
> >> +
> >> +// plplot headers
> >> +#include "plplotP.h"
> >> +#include "drivers.h"
> >>    // PLplot headers
> >>    #include "plDevs.h"
> >>    #include "wxwidgets.h" // includes wx/wx.h
> >>
> >>
> >>
> >>
> >> Le 22/09/2018 à 01:37, Phil Rosenberg a écrit :
> >>> Hi Laurent
> >>> What a strange set of compilation errors. They are all from windows
> >>> sockets headers, rather than from wxWidgets.
> >>>
> >>> Here is my guess at what is happening - but I have not been able to
> >>> reproduce the error (I am using VS 2015 still).
> >>>
> >>> In the code before your edits following the #includes through, it
> >>> turns out we include <windows.h> into wxwidgets_dev.cpp before any
> >>> wxWidgets headers. This is done via "wxwidgets.h", then
> >>> "wxwidgets_comms.h". The winsock related functions probably get pulled
> >>> in via windows.h. I have a feeling that one of the wx headers is then
> >>> pulling in alternate definitions of those winsock functions, but I'm
> >>> not sure from where.
> >>>
> >>> By shuffling the headers round as you have, you include <wx/wx.h>
> >>> before we pull in <windows.h>. The <wx/wx.h> file will in turn pull in
> >>> <windows.h> itself. then our include windows.h should get ignored.
> >>>
> >>> I can't think how exectly it might work, but I bet there is some weird
> >>> inconsistency between how <windows.h> is pulled in by us, vs how it is
> >>> pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
> >>> or extern "C".
> >>>
> >>> Anyway I might guess that moving the headers around is simply masking
> >>> some other problem. Can I check that you have built wxWidgets with the
> >>> same virsion of visual studio? And that it is also built as a static
> >>> lib? Just a hunch but maybe something to do with the wxwidgets library
> >>> configuration is causing the issue.
> >>>
> >>> Phil
> >>> On Fri, 21 Sep 2018 at 23:08, Alan W. Irwin <Ala...@gm...> wrote:
> >>>> On 2018-09-21 18:38+0200 Laurent Berger wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
> >>>>> ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
> >>>>>
> >>>>> and delete cmakecache.txt and I I'm trying to build plplot in static
> >>>>>
> >>>>> BUILD_SHARED_LIBS:BOOL=OFF
> >>>>>
> >>>>> and ENABLE_DYNDRIVERS:BOOL=OFF
> >>>>>
> >>>>> and I have got 59 errors compiling wxwidgets_dev.cpp.
> >>>>>
> >>>>> In git repo I can find this file
> >>>>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
> >>>>>
> >>>>> I copy
> >>>>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36
> >>>>> and insert those lines here
> >>>>> https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
> >>>>>
> >>>>> I can compile and link plplot.
> >>>> Hi Laurent:
> >>>>
> >>>> Thanks for your test of my recent PLplot development activity.
> >>>>
> >>>> I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
> >>>> and caf4801dfe (current master tip), and your description of the
> >>>> required change appears to correspond to copying some wxwidgets includes from
> >>>> one part of the old commit (or alternatively the latest commit since
> >>>> those lines haven't changed) to just after
> >>>>
> >>>> #include "wxwidgets.h"
> >>>>
> >>>> As far as I can tell such a copy of includes should have zero effect
> >>>> so it appears either I misunderstood the change you described above or
> >>>> else the github repo for PLplot is not properly up to date with the
> >>>> definitive SourceForge repo.  So to remove this uncertainty please
> >>>> give us the results of
> >>>>
> >>>> git diff
> >>>>
> >>>> to describe the definitive version of the change to the master tip of
> >>>> PLplot that works for you (i.e., allows a static build of PLplot to
> >>>> compile and link for your VS2017 platform).
> >>>>
> >>>> By the way, a comprehensive test of PLplot has recently (one commit
> >>>> behind master tip) worked perfectly here on Linux (Debian Buster).
> >>>> Such comprehensive tests include not only building a static wxwidgets
> >>>> device but run-time testing it as well.  Also that last commit on the
> >>>> master branch is a minor one involving how to control the Lua version
> >>>> that is searched for and is therefore extremely unlikely to introduce
> >>>> wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
> >>>> so someone with access to recent Windows platforms will have to
> >>>> attempt that instead.
> >>>>
> >>>> Alan
> >>>> __________________________
> >>>> Alan W. Irwin
> >>>>
> >>>> 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-devel mailing list
> >>>> Plp...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Alan W. I. <Ala...@gm...>]

On 2018-09-22 23:16+0100 Phil Rosenberg wrote:

> Hi Laurent
>
> I have implemented your first solution. If you could let me know that
> things now work for you that would be great.

Hi Phil:

Although your question was addressed to Laurent, it should interest
you to know your fix causes no issues for Linux (i.e., building the
test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build
or run-time issues).

Alan
__________________________
Alan W. Irwin

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-devel] Cannot compile plplot using VS 2017

[Phil R. <p.d...@gm...>]

Excellent, thanks Alan
On Sun, 23 Sep 2018 at 01:25, Alan W. Irwin <Ala...@gm...> wrote:
>
> On 2018-09-22 23:16+0100 Phil Rosenberg wrote:
>
> > Hi Laurent
> >
> > I have implemented your first solution. If you could let me know that
> > things now work for you that would be great.
>
> Hi Phil:
>
> Although your question was addressed to Laurent, it should interest
> you to know your fix causes no issues for Linux (i.e., building the
> test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build
> or run-time issues).
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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-devel] Cannot compile plplot using VS 2017

[Laurent B. <lau...@un...>]

Hi,

https://sourceforge.net/p/plplot/plplot/ci/4a5f94a70ac259d696dfaa8117cead7ad89b13f3/ 
: It works thanks!


New file is now

// Headers needed for Rand
#ifdef _WIN32
// This include must occur before any other include of stdlib.h due to
// the #define _CRT_RAND_S
#define _CRT_RAND_S
#include <stdlib.h>
#else
#include <fstream>
#endif

// wxwidgets headers
#include <wx/wx.h>
#include <wx/dir.h>
#include <wx/ustring.h>
// PLplot headers
#include "plDevs.h"
#include "wxwidgets.h" // includes wx/wx.h


// std and driver headers
#include <cmath>
#include <limits>


Le 23/09/2018 à 02:23, Alan W. Irwin a écrit :
> On 2018-09-22 23:16+0100 Phil Rosenberg wrote:
>
>> Hi Laurent
>>
>> I have implemented your first solution. If you could let me know that
>> things now work for you that would be great.
>
> Hi Phil:
>
> Although your question was addressed to Laurent, it should interest
> you to know your fix causes no issues for Linux (i.e., building the
> test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build
> or run-time issues).
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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-devel] Cannot compile plplot using VS 2017

[Phil R. <p.d...@gm...>]

Good news! Thanks for reporting the problem.

Phil

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Laurent Berger <lau...@un...>
Sent: Sunday, September 23, 2018 11:12:50 AM
To: Alan W. Irwin; Phil Rosenberg
Cc: PLplot development list
Subject: Re: [Plplot-devel] Cannot compile plplot using VS 2017

Hi,

https://sourceforge.net/p/plplot/plplot/ci/4a5f94a70ac259d696dfaa8117cead7ad89b13f3/
: It works thanks!


New file is now

// Headers needed for Rand
#ifdef _WIN32
// This include must occur before any other include of stdlib.h due to
// the #define _CRT_RAND_S
#define _CRT_RAND_S
#include <stdlib.h>
#else
#include <fstream>
#endif

// wxwidgets headers
#include <wx/wx.h>
#include <wx/dir.h>
#include <wx/ustring.h>
// PLplot headers
#include "plDevs.h"
#include "wxwidgets.h" // includes wx/wx.h


// std and driver headers
#include <cmath>
#include <limits>


Le 23/09/2018 à 02:23, Alan W. Irwin a écrit :
> On 2018-09-22 23:16+0100 Phil Rosenberg wrote:
>
>> Hi Laurent
>>
>> I have implemented your first solution. If you could let me know that
>> things now work for you that would be great.
>
> Hi Phil:
>
> Although your question was addressed to Laurent, it should interest
> you to know your fix causes no issues for Linux (i.e., building the
> test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build
> or run-time issues).
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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-devel] How to use plplot in my own project?

[Laurent B. <lau...@un...>]

Hi,

I want to use plplot in my own project using cmake and I miss something. 
my cmakelists.txt is see below and it works. But in include_directories 
cmake command I must write :

include_directories(${plplot_DIR}/../../../include) and it is really 
weird. what's variable name for include ?

Another strange behavior: in debug and release lib generated by cmake 
installation are the same plplot.lib  and it should be something like 
plplot.lib and plplotd.lib. I can find export_plplot-debug.cmake and 
export_plplot-release.cmake so i think it could be possible to add a d 
in export_plplot-debug.cmake for all libs


CMakeLists.txt

cmake_minimum_required(VERSION 3.0)

set(NomProjet examplePlplot)
PROJECT (${NomProjet})
find_package(OpenCV  REQUIRED)
find_package(wxWidgets COMPONENTS core base net adv aui html  qa 
richtext stc ribbon xml gl REQUIRED)
find_package(plplot)

file(GLOB Projet_SRCS
     "*.h"
     "*.cpp")

ADD_EXECUTABLE (${NomProjet} ${Projet_SRCS} )

if (wxWidgets_FOUND)
     include_directories(${wxWidgets_INCLUDE_DIRS} ${OpenCV_INCLUDE_DIRS})
     target_link_libraries (${NomProjet} LINK_PUBLIC ${OpenCV_LIBS} 
${wxWidgets_LIBRARIES} )
endif (wxWidgets_FOUND)
if (plplot_FOUND)

     include_directories(${plplot_DIR}/../../../include)
     target_link_libraries( ${NomProjet} PUBLIC PLPLOT::plplotwxwidgets)
else (plplot_FOUND)
message( " PROBLEME" )
endif(plplot_FOUND)


SET(wxWidgets_DEFINITIONS WXUSINGDLL)
set_target_properties(${NomProjet} PROPERTIES  COMPILE_DEFINITIONS 
"${wxWidgets_DEFINITIONS};__WXMSW__;_CRT_SECURE_NO_WARNINGS")
set_target_properties(${NomProjet} PROPERTIES LINK_FLAGS_DEBUG 
"/SUBSYSTEM:CONSOLE")
set_target_properties(${NomProjet} PROPERTIES LINK_FLAGS_RELEASE 
"/SUBSYSTEM:CONSOLE")




Le 23/09/2018 à 12:12, Laurent Berger a écrit :
> Hi,
>
> https://sourceforge.net/p/plplot/plplot/ci/4a5f94a70ac259d696dfaa8117cead7ad89b13f3/ 
> : It works thanks!
>
>
> New file is now
>
> // Headers needed for Rand
> #ifdef _WIN32
> // This include must occur before any other include of stdlib.h due to
> // the #define _CRT_RAND_S
> #define _CRT_RAND_S
> #include <stdlib.h>
> #else
> #include <fstream>
> #endif
>
> // wxwidgets headers
> #include <wx/wx.h>
> #include <wx/dir.h>
> #include <wx/ustring.h>
> // PLplot headers
> #include "plDevs.h"
> #include "wxwidgets.h" // includes wx/wx.h
>
>
> // std and driver headers
> #include <cmath>
> #include <limits>
>
>
> Le 23/09/2018 à 02:23, Alan W. Irwin a écrit :
>> On 2018-09-22 23:16+0100 Phil Rosenberg wrote:
>>
>>> Hi Laurent
>>>
>>> I have implemented your first solution. If you could let me know that
>>> things now work for you that would be great.
>>
>> Hi Phil:
>>
>> Although your question was addressed to Laurent, it should interest
>> you to know your fix causes no issues for Linux (i.e., building the
>> test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build
>> or run-time issues).
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> 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-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] How to use plplot in my own project?

[Alan W. I. <Ala...@gm...>]

On 2018-09-25 22:05+0200 Laurent Berger wrote:

> Hi,
>
> I want to use plplot in my own project using cmake and I miss something. my 
> cmakelists.txt is see below and it works. But in include_directories cmake 
> command I must write :
>
> include_directories(${plplot_DIR}/../../../include) and it is really weird. 
> what's variable name for include ?

[...]

> CMakeLists.txt
>
[...]
> find_package(plplot)
[...]
> ADD_EXECUTABLE (${NomProjet} ${Projet_SRCS} )
[...]
> if (plplot_FOUND)
>
>     include_directories(${plplot_DIR}/../../../include)
>     target_link_libraries( ${NomProjet} PUBLIC PLPLOT::plplotwxwidgets)
> else (plplot_FOUND)
> message( " PROBLEME" )
> endif(plplot_FOUND)

Hi Laurent:

I have reviewed the redacted version above, and all seems well.  For
example, our installed examples are similarly built against the
installed version of PLplot, and what you have implemented above
follows that same method.  For example, you can see
"find_package(plplot)" (in the non-CORE_BUILD part of
examples/CMakeLists.txt), and a combination of add_executable,
include_directories (which refers to the installed location of PLplot
for the non-CORE_BUILD case just like you apparently have
implemented), and target_link_libraries in examples/c/CMakeLists.txt.

However, you were right to question that include_directories command
which is necessary now, but should not be necessary in future once I
set up the export of PLplot to handle compile options properly.  But
that implementation is a little tricky so although it is on my ToDo
list now, I am going to put it off until after the 5.14.0 release that
is coming soon.

Alan
__________________________
Alan W. Irwin

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-devel] How to use plplot in my own project?

[Phil R. <p.d...@gm...>]

Hi Laurent
Just a not about naming - I too expected a d suffix on the library
name to represent debug when I first started using plplot. There used
to be a cmake option to add a suffix to the name, but it is no longer
listed on https://sourceforge.net/p/plplot/wiki/CMake_options_for_PLplot/
- Alan do you know if it is still implemented and if so what it is?
There used to be a d suffix added to represent the fact that the
library was built with double precision floating point variables, but
I don't think this is the case any more.

I used to add the d suffix for debug builds, but in the end I stopped.
I came across too many libraries that didn't do it. I have a feeling
it is an inherently windows style thing (you only need debug libraries
if they are static rather than shared and Linux users never seem to
build static libraries), so many Linux-centric open source projects
don't do it. Maybe I'm wrong in saying this, it's only my thoughts.
Anyway, my solution was to install my debug libraries in a folder
specific to debug libraries. Almost every library has a way to specify
the install prefix. With plplot you can do this with the
-DCMAKE_LIBRARY_PATH or -DCMAKE_INSTALL_PREFIX

Whether you go for a prefix option or if a suffix is possible you will
need to run cmake twice, once for release and once for debug and once
for release by setting the -DCMAKE_CONFIGURATION_TYPES options to
"Debug" or "Release".

Phil
On Tue, 25 Sep 2018 at 22:08, Alan W. Irwin <Ala...@gm...> wrote:
>
> On 2018-09-25 22:05+0200 Laurent Berger wrote:
>
> > Hi,
> >
> > I want to use plplot in my own project using cmake and I miss something. my
> > cmakelists.txt is see below and it works. But in include_directories cmake
> > command I must write :
> >
> > include_directories(${plplot_DIR}/../../../include) and it is really weird.
> > what's variable name for include ?
>
> [...]
>
> > CMakeLists.txt
> >
> [...]
> > find_package(plplot)
> [...]
> > ADD_EXECUTABLE (${NomProjet} ${Projet_SRCS} )
> [...]
> > if (plplot_FOUND)
> >
> >     include_directories(${plplot_DIR}/../../../include)
> >     target_link_libraries( ${NomProjet} PUBLIC PLPLOT::plplotwxwidgets)
> > else (plplot_FOUND)
> > message( " PROBLEME" )
> > endif(plplot_FOUND)
>
> Hi Laurent:
>
> I have reviewed the redacted version above, and all seems well.  For
> example, our installed examples are similarly built against the
> installed version of PLplot, and what you have implemented above
> follows that same method.  For example, you can see
> "find_package(plplot)" (in the non-CORE_BUILD part of
> examples/CMakeLists.txt), and a combination of add_executable,
> include_directories (which refers to the installed location of PLplot
> for the non-CORE_BUILD case just like you apparently have
> implemented), and target_link_libraries in examples/c/CMakeLists.txt.
>
> However, you were right to question that include_directories command
> which is necessary now, but should not be necessary in future once I
> set up the export of PLplot to handle compile options properly.  But
> that implementation is a little tricky so although it is on my ToDo
> list now, I am going to put it off until after the 5.14.0 release that
> is coming soon.
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] How to use plplot in my own project?

[Laurent B. <lau...@un...>]

In a small project https://github.com/LaurentBerger/AAPlus, I use this 
https://stackoverflow.com/questions/29971026/generator-expression-for-install-commands 



Le 29/09/2018 à 10:53, Phil Rosenberg a écrit :
> Hi Laurent
> Just a not about naming - I too expected a d suffix on the library
> name to represent debug when I first started using plplot. There used
> to be a cmake option to add a suffix to the name, but it is no longer
> listed on https://sourceforge.net/p/plplot/wiki/CMake_options_for_PLplot/
> - Alan do you know if it is still implemented and if so what it is?
> There used to be a d suffix added to represent the fact that the
> library was built with double precision floating point variables, but
> I don't think this is the case any more.
>
> I used to add the d suffix for debug builds, but in the end I stopped.
> I came across too many libraries that didn't do it. I have a feeling
> it is an inherently windows style thing (you only need debug libraries
> if they are static rather than shared and Linux users never seem to
> build static libraries), so many Linux-centric open source projects
> don't do it. Maybe I'm wrong in saying this, it's only my thoughts.
> Anyway, my solution was to install my debug libraries in a folder
> specific to debug libraries. Almost every library has a way to specify
> the install prefix. With plplot you can do this with the
> -DCMAKE_LIBRARY_PATH or -DCMAKE_INSTALL_PREFIX
>
> Whether you go for a prefix option or if a suffix is possible you will
> need to run cmake twice, once for release and once for debug and once
> for release by setting the -DCMAKE_CONFIGURATION_TYPES options to
> "Debug" or "Release".
>
> Phil
> On Tue, 25 Sep 2018 at 22:08, Alan W. Irwin <Ala...@gm...> wrote:
>> On 2018-09-25 22:05+0200 Laurent Berger wrote:
>>
>>> Hi,
>>>
>>> I want to use plplot in my own project using cmake and I miss something. my
>>> cmakelists.txt is see below and it works. But in include_directories cmake
>>> command I must write :
>>>
>>> include_directories(${plplot_DIR}/../../../include) and it is really weird.
>>> what's variable name for include ?
>> [...]
>>
>>> CMakeLists.txt
>>>
>> [...]
>>> find_package(plplot)
>> [...]
>>> ADD_EXECUTABLE (${NomProjet} ${Projet_SRCS} )
>> [...]
>>> if (plplot_FOUND)
>>>
>>>      include_directories(${plplot_DIR}/../../../include)
>>>      target_link_libraries( ${NomProjet} PUBLIC PLPLOT::plplotwxwidgets)
>>> else (plplot_FOUND)
>>> message( " PROBLEME" )
>>> endif(plplot_FOUND)
>> Hi Laurent:
>>
>> I have reviewed the redacted version above, and all seems well.  For
>> example, our installed examples are similarly built against the
>> installed version of PLplot, and what you have implemented above
>> follows that same method.  For example, you can see
>> "find_package(plplot)" (in the non-CORE_BUILD part of
>> examples/CMakeLists.txt), and a combination of add_executable,
>> include_directories (which refers to the installed location of PLplot
>> for the non-CORE_BUILD case just like you apparently have
>> implemented), and target_link_libraries in examples/c/CMakeLists.txt.
>>
>> However, you were right to question that include_directories command
>> which is necessary now, but should not be necessary in future once I
>> set up the export of PLplot to handle compile options properly.  But
>> that implementation is a little tricky so although it is on my ToDo
>> list now, I am going to put it off until after the 5.14.0 release that
>> is coming soon.
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> 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-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] How to use plplot in my own project?

[Alan W. I. <Ala...@gm...>]

On 2018-09-29 09:53+0100 Phil Rosenberg wrote:

[...]
> - Alan do you know if it [library suffix] is still implemented and if so what it is?
> There used to be a d suffix added to represent the fact that the
> library was built with double precision floating point variables, but
> I don't think this is the case any more.

We dropped library suffixes some time ago because of the much cleaner
solution you state below.

[...]
> Anyway, my solution was to install my debug libraries in a folder
> specific to debug libraries. Almost every library has a way to specify
> the install prefix. With plplot you can do this with the
> -DCMAKE_LIBRARY_PATH or -DCMAKE_INSTALL_PREFIX

Exactly.

Alan
__________________________
Alan W. Irwin

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
__________________________