plplot-devel — Technical discussion about PLplot development

[Plplot-devel] More tclmatrix library progress

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

On 2016-11-05 00:40-0700 Alan W. Irwin wrote:

[...]
> N.B. I have not yet made any changes in the matrix initialization
> code nor the matrix assignment code. [....]

I have completed that work as of commit ad34b3a.  Please see the
commit message for examples of the large degree of flexibility (any
combination of space separated numbers, complex lists (of lists of
lists....) of numbers, and array slice references) I have now
implemented for the format of RHS of the "=" sign for both matrix
initialization and assignment. Thus, the goal of having complete
multi-dimensional matrix resizing and reshaping capabilities under Tcl
has now been realized, and that should allow me to drop all the
non-redacted forms from our Tcl and Tk bindings and examples which is
the Tcl/Tk project I plan to start tomorrow.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Just finished implementing a powerful index slice capability for the tclmatrix library

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

Hi Arjen:

Please see the commit message for commit aab3994 for more details
concerning this new tclmatrix capability that I have implemented that
we have previously discussed off list.  In particular please take a
look at the new bindings/tcl/test_tclmatrix.tcl file for extensive
examples of what is possible with this new capability, and when you
get a chance, please build the "check_libtclmatrix_capabilities"
target on Cygwin to make sure that you can use all these new
facilities on that platform.

N.B. I have not yet made any changes in the matrix initialization
code nor the matrix assignment code, but by accident I discovered
that

matrix x f 4 = {0., 1., 2., 3.}
maxtrix y f 2 = [x 0:2]

initializes y with the first two elements of x (where "0:2" is the
index slice that selects those).  However, I could not get this to
work for multidimensional arrays.  (In fact, I could get no
initialization of either of the two forms above to work for those
kinds of arrays.) So there is more work that I need to do in those
areas, but I believe I am fairly close now to the goal of having complete
multi-dimensional matrix resizing and reshaping capabilities under
Tcl.  And once we have that capability, that should allow you to drop
all the non-redacted forms from our Tcl and Tk bindings and examples
which is a substantial Tcl/Tk improvement for PLplot that I have
been looking forward to for a long time.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Finding wxWidgets

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

N.B. I have just (commit 3ab6396) updated the PLplot wxWidgets find
module again to conform (identically except for one necessary line) to
the latest (CMake-3.7.0-rc2) official version.  See the commit log
message for a description of the changes in the PLplot version of this
find module (which we are maintaining separately from the official
version since that version is being actively maintained and many of
our users are using a CMake version that is earlier than
CMake-3.7.0-rc2 so would access a buggy version of this find module
unless we supply the latest version like this).

I am pretty sure this latest version will work fine for everybody
(since it is maintained by the CMake developer team who are responding
so actively to bug reports concerning it), but further tests by
everybody to confirm good wxWidgets find results using our latest
master branch would be much appreciated.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Finding wxWidgets

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

I was never very good with cmake, but the old findwxwidgets cmake module never worked on windows for me, which is why we had our own. I thought I'd checked things since we went back to the built in module, but perhaps it wasn't a clean build tree. I'll check again tomorrow.

Phil

Sent from my Windows 10 phone

From: Laurent Berger
Sent: 19 October 2016 20:46
To: plp...@li...
Subject: Re: [Plplot-devel] Finding wxWidgets

Hi all,

I still use plplot  (PLplot Release 5.11.2) and wxwidgets (from github) 
using cmake with vs 2015. If you want to check something about detect 
wxwidgets feel free to ask me.

Laurent
Le 19/10/2016 à 21:39, Alan W. Irwin a écrit :
> On 2016-10-19 00:10-0400 Pedro Vicente wrote:
>
>> 2) wxWidgets not detected
>>
>>
>> I used
>>
>>
>>
>> M:\plplot-plplot\build>cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON
>> -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug"
>> -DCMAKE_BUILD_TYP
>> E:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON
>> -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN%
>> -DwxWidgets_LIB_DIR:PATH=%WX
>> WIN%\lib\vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON
>> -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
>> -DCMAKE_PREFIX_PATH:PATH=I:\qt-win32-msvc20
>> 15 -DPLPLOT_USE_QT5:BOOL=ON > a.txt 2>&1
>>
>> and the a.txt file is attached
> Hi Pedro:
>
> I think this topic deserves its own thread so note the subject line
> change.  I looked at your a.txt file, and indeed
>
> -- wxWidgets_FOUND           : FALSE
> -- wxWidgets_INCLUDE_DIRS    :
> -- wxWidgets_LIBRARY_DIRS    :
> -- wxWidgets_LIBRARIES       :
> -- wxWidgets_CXX_FLAGS       :
> -- wxWidgets_USE_FILE        : UsewxWidgets
> -- WARNING: wxWidgets or its libraries not found so setting all wxwidgets devices to OFF.
>
> But then you look near the end of that file, and you find this
> interesting tidbit.
>
> CMake Warning:
>     Manually-specified variables were not used by the project:
>
>       ENABLE_MIX_CXX
>       wxWidgets_CONFIGURATION
>
> What did you mean to do with the -DENABLE_MIX_CXX=ON cmake
> command-line option?  I can find no reference
> at all to the string "_MIX" in our source tree or in the near-complete cmake
> documentation you get by running cmake --help-full so I suspect you
> have mispelled that option.
>
> In contrast to ENABLE_MIX_CXX, wxWidgets_CONFIGURATION is readily found
> in cmake/modules/FindwxWidgets.cmake, but you are obviously not getting
> to that part of the logic which is likely due to some incorrect setup
> of the search for wxWidgets that you are doing.  So I would carefully
> review the other wxWidgets command-line options you are using.  For
> example you specify
>
> -DwxWidgets_ROOT_DIR:PATH=%WXWIN%
>
> Is "WXWIN" set correctly?  For example, the
> find module documentation in cmake/modules/FindwxWidgets.cmake uses
> the example of C:/wxWidgets-2.6.3 so you should check that WXWIN
> translates to the equivalent for your wxWidgets-3.1.0 installation.
> And similarly for -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib
>
> Once you have WXWIN set correctly (or whatever is needed to change
> your wxWidgets cmake command-line options so that
> wxWidgets_CONFIGURATION is used), then my prediction is the rest
> of the wxWidgets find process will work as well.  But please let me
> know whether this prediction pans out.  :-)
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Finding wxWidgets

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

Hi all,

I still use plplot  (PLplot Release 5.11.2) and wxwidgets (from github) 
using cmake with vs 2015. If you want to check something about detect 
wxwidgets feel free to ask me.

Laurent
Le 19/10/2016 à 21:39, Alan W. Irwin a écrit :
> On 2016-10-19 00:10-0400 Pedro Vicente wrote:
>
>> 2) wxWidgets not detected
>>
>>
>> I used
>>
>>
>>
>> M:\plplot-plplot\build>cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON
>> -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug"
>> -DCMAKE_BUILD_TYP
>> E:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON
>> -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN%
>> -DwxWidgets_LIB_DIR:PATH=%WX
>> WIN%\lib\vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON
>> -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
>> -DCMAKE_PREFIX_PATH:PATH=I:\qt-win32-msvc20
>> 15 -DPLPLOT_USE_QT5:BOOL=ON > a.txt 2>&1
>>
>> and the a.txt file is attached
> Hi Pedro:
>
> I think this topic deserves its own thread so note the subject line
> change.  I looked at your a.txt file, and indeed
>
> -- wxWidgets_FOUND           : FALSE
> -- wxWidgets_INCLUDE_DIRS    :
> -- wxWidgets_LIBRARY_DIRS    :
> -- wxWidgets_LIBRARIES       :
> -- wxWidgets_CXX_FLAGS       :
> -- wxWidgets_USE_FILE        : UsewxWidgets
> -- WARNING: wxWidgets or its libraries not found so setting all wxwidgets devices to OFF.
>
> But then you look near the end of that file, and you find this
> interesting tidbit.
>
> CMake Warning:
>     Manually-specified variables were not used by the project:
>
>       ENABLE_MIX_CXX
>       wxWidgets_CONFIGURATION
>
> What did you mean to do with the -DENABLE_MIX_CXX=ON cmake
> command-line option?  I can find no reference
> at all to the string "_MIX" in our source tree or in the near-complete cmake
> documentation you get by running cmake --help-full so I suspect you
> have mispelled that option.
>
> In contrast to ENABLE_MIX_CXX, wxWidgets_CONFIGURATION is readily found
> in cmake/modules/FindwxWidgets.cmake, but you are obviously not getting
> to that part of the logic which is likely due to some incorrect setup
> of the search for wxWidgets that you are doing.  So I would carefully
> review the other wxWidgets command-line options you are using.  For
> example you specify
>
> -DwxWidgets_ROOT_DIR:PATH=%WXWIN%
>
> Is "WXWIN" set correctly?  For example, the
> find module documentation in cmake/modules/FindwxWidgets.cmake uses
> the example of C:/wxWidgets-2.6.3 so you should check that WXWIN
> translates to the equivalent for your wxWidgets-3.1.0 installation.
> And similarly for -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib
>
> Once you have WXWIN set correctly (or whatever is needed to change
> your wxWidgets cmake command-line options so that
> wxWidgets_CONFIGURATION is used), then my prediction is the rest
> of the wxWidgets find process will work as well.  But please let me
> know whether this prediction pans out.  :-)
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Finding wxWidgets

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

On 2016-10-19 00:10-0400 Pedro Vicente wrote:

> 2) wxWidgets not detected
>
>
> I used
>
>
>
> M:\plplot-plplot\build>cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON 
> -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" 
> -DCMAKE_BUILD_TYP
> E:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON 
> -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% 
> -DwxWidgets_LIB_DIR:PATH=%WX
> WIN%\lib\vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON 
> -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF 
> -DCMAKE_PREFIX_PATH:PATH=I:\qt-win32-msvc20
> 15 -DPLPLOT_USE_QT5:BOOL=ON > a.txt 2>&1
>
> and the a.txt file is attached

Hi Pedro:

I think this topic deserves its own thread so note the subject line
change.  I looked at your a.txt file, and indeed

-- wxWidgets_FOUND           : FALSE
-- wxWidgets_INCLUDE_DIRS    : 
-- wxWidgets_LIBRARY_DIRS    : 
-- wxWidgets_LIBRARIES       : 
-- wxWidgets_CXX_FLAGS       : 
-- wxWidgets_USE_FILE        : UsewxWidgets
-- WARNING: wxWidgets or its libraries not found so setting all wxwidgets devices to OFF.

But then you look near the end of that file, and you find this
interesting tidbit.

CMake Warning:
   Manually-specified variables were not used by the project:

     ENABLE_MIX_CXX
     wxWidgets_CONFIGURATION

What did you mean to do with the -DENABLE_MIX_CXX=ON cmake
command-line option?  I can find no reference
at all to the string "_MIX" in our source tree or in the near-complete cmake
documentation you get by running cmake --help-full so I suspect you
have mispelled that option.

In contrast to ENABLE_MIX_CXX, wxWidgets_CONFIGURATION is readily found
in cmake/modules/FindwxWidgets.cmake, but you are obviously not getting
to that part of the logic which is likely due to some incorrect setup
of the search for wxWidgets that you are doing.  So I would carefully
review the other wxWidgets command-line options you are using.  For
example you specify

-DwxWidgets_ROOT_DIR:PATH=%WXWIN%

Is "WXWIN" set correctly?  For example, the
find module documentation in cmake/modules/FindwxWidgets.cmake uses
the example of C:/wxWidgets-2.6.3 so you should check that WXWIN
translates to the equivalent for your wxWidgets-3.1.0 installation.
And similarly for -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib

Once you have WXWIN set correctly (or whatever is needed to change
your wxWidgets cmake command-line options so that
wxWidgets_CONFIGURATION is used), then my prediction is the rest
of the wxWidgets find process will work as well.  But please let me
know whether this prediction pans out.  :-)

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] cmake error Qt build

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

On 2016-10-19 00:10-0400 Pedro Vicente wrote:

> Hi Alan
> Cmake had no errors this time

Great!

>
> I still have
> 1) Qt linking errors .
> might be because of my custom Qt build; I'll try to test with an "official" 
> Qt build in the next couple days.

I assume you are referring to the following link error
[out of order]

> Creating library M:/plplot-plplot/build/examples/c++/Debug/qt_example.lib and 
> object M:/plplot-plplot/build/examples/c++/Debug/qt_example.exp
> Qt5Guid.lib(qfontengine.obj) : error LNK2019: unresolved external symbol 
> _hb_ot_tags_from_script referenced in function "public: bool __thiscall 
> QFontEngine::supportsScript(enum QChar::Script)const " 
> (?supportsScript@QFontEngine@@QBE_NW4Script@QChar@@@Z)
> Qt5Guid.lib(qfontengine.obj) : error LNK2019: unresolved external symbol 
> _hb_ot_layout_table_find_script referenced in function "public: bool 
> __thiscall QFontEngine::supportsScript
>

Building qt_example with Qt5 should "just work" on Windows like it
currently does for me on Linux.  Therefore, if moving to an "official"
Qt5 build does not fix this for you, then there is more work for us to
do to jointly debug this.

> What is the release date of the next PLplot?

I am hoping by early December, but I don't really know at this stage.
There is still a lot of open-ended stuff I want to do such as finish
off my large documentation update and other more minor topics.  And I
am hoping for development efforts from others as well (such as Arjen
finishing his work so that Tcl gets completely converted to the
redacted argument model).

> Would it be possible to have a 
> "release canditate" version for user's testing?

We make quite an effort to keep git master branch in good shape so we
encourage users to try it as part of on-going testing (just like you
are doing now).  Once we go into freeze prior to the release where
only documentation changes are allowed for the master branch, then the
master branch will be equivalent to a release candidate.  I doubt I
will make an official release candidate at that stage, but I will
certainly publish an appeal for intense user testing then (typically
in the last week before the actual release).  But your on-going testing
of git master branch now is extremely useful as well.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] [SPAM]Re: cmake error Qt build

[Pedro V. <ped...@sp...>]

Hi Alan
Cmake had no errors this time

I still have
1) Qt linking errors .
might be because of my custom Qt build; I'll try to test with an "official" 
Qt build in the next couple days.

What is the release date of the next PLplot? Would it be possible to have a 
"release canditate" version for user's testing?

2) wxWidgets not detected


I used



M:\plplot-plplot\build>cmake ".." -G "Visual Studio 
14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" 
 -DCMAKE_BUILD_TYP
E:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON 
 -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WX
WIN%\lib\vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF 
 -DCMAKE_PREFIX_PATH:PATH=I:\qt-win32-msvc20
15 -DPLPLOT_USE_QT5:BOOL=ON > a.txt 2>&1

and the a.txt file is attached


 Creating library M:/plplot-plplot/build/examples/c++/Debug/qt_example.lib 
and object M:/plplot-plplot/build/examples/c++/Debug/qt_example.exp
Qt5Guid.lib(qfontengine.obj) : error LNK2019: unresolved external symbol 
_hb_ot_tags_from_script referenced in function "public: bool __thiscall 
QFontEngine::supportsScript(enum QChar::Script)const " 
(?supportsScript@QFontEngine@@QBE_NW4Script@QChar@@@Z)
Qt5Guid.lib(qfontengine.obj) : error LNK2019: unresolved external symbol 
_hb_ot_layout_table_find_script referenced in function "public: bool 
__thiscall QFontEngine::supportsScript

thanks

-Pedro






----- Original Message ----- 
From: "Pedro Vicente" <ped...@sp...>
To: "Alan W. Irwin" <ir...@be...>; "Hazen Babcock" 
<hba...@ma...>
Cc: "PLplot development list" <Plp...@li...>
Sent: Saturday, October 15, 2016 9:07 PM
Subject: [SPAM]Re: [Plplot-devel] cmake error Qt build


> Hi Alan
>
> Thank you for your effort in debuging this.
> I send some results here attached , and I'll keep trying other options
> later.
> by the way, wxWidgets is also not detected.
>
> I wonder, could this be a Windows only issue? Because you are trying on
> Linux, correct?
>
> Tradionally I set the location of Qt with the environment
> QTDIR=<path>
> but I did some search on the detection of Qt by cmake on the official docs
>
>
> http://doc.qt.io/qt-5/cmake-manual.html
>
> and they say
>
> "The easiest way to use CMake is to set the CMAKE_PREFIX_PATH environment
> variable to the install prefix of Qt 5."
>
> so I tried that instead
>
> also here
>
> https://www.kdab.com/using-cmake-with-qt-5/
>
> they specificaly say to *not* use the form
>
> find_package(Qt5
>
> but that is a resource from 2012, not sure if that is valid
>
> I did
>
> on Windows
> git clone of plplot
> using Visual Studio 2014
> Qt 5.5.1 static build compiled by me
> cmake 3.6.2
> wxWidgets 3.1.0
>
>
> cmake ".." -G "Visual Studio
> 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug"
> -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON
> -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib
> -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
> -DCMAKE_PREFIX_PATH:PATH=I:\qt-win32-msvc2015 -DPLPLOT_USE_QT5:BOOL=ON
>
>
> I have some errors
>
> first, the Qt location is detected
>
> -- Qt5_library_fullpath_list =
> I:/qt-win32-msvc2015/lib/Qt5Cored.lib;I:/qt-win32-msvc2015/lib/Qt5Guid.lib;I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib;I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib;I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
> -- Qt5_library_LINK_FLAGS = I:/qt-win32-msvc2015/lib/Qt5Cored.lib
> I:/qt-win32-msvc2015/lib/Qt5Guid.lib
> I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib
> I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib
> I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
>
>
>
> but then the errors are
>
>
> CMake Error at src/CMakeLists.txt:322 (target_link_libraries):
>  The plain signature for target_link_libraries has already been used with
>  the target "plplot".  All uses of target_link_libraries with a target 
> must
>  be either all-keyword or all-plain.
>
>  The uses of the plain signature are here:
>
>   * I:/qt-win32-msvc2015/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:330
> (target_link_libraries)
>
>
>
> libplplot_LINK_FLAGS = C:/Program Files (x86)/Windows
> Kits/8.1/Lib/winv6.3/um/x86/Gdi32.Lib;C:/Program Files (x86)/Windows
> Kits/8.1/Lib/winv6.3/um/x86/ComDlg32.Lib;-lcsirocsa;-lqsastime;I:/qt-win32-msvc2015/lib/Qt5Cored.lib
> I:/qt-win32-msvc2015/lib/Qt5Guid.lib
> I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib
> I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib
> I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
> -- WARNING: Perl modules XML::Parser and/or XML::DOM not available
>   so cannot check that swig_documentation.i is up to date.
> CMake Error at bindings/qt_gui/CMakeLists.txt:57 (target_link_libraries):
>  The plain signature for target_link_libraries has already been used with
>  the target "plplotqt".  All uses of target_link_libraries with a target
>  must be either all-keyword or all-plain.
>
>  The uses of the plain signature are here:
>
>   * I:/qt-win32-msvc2015/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:330
> (target_link_libraries)
>
>
>
> -Pedro
>
> ----- Original Message ----- 
> From: "Alan W. Irwin" <ir...@be...>
> To: "Hazen Babcock" <hba...@ma...>; "Pedro Vicente"
> <ped...@sp...>
> Cc: "PLplot development list" <Plp...@li...>
> Sent: Saturday, October 15, 2016 6:50 PM
> Subject: [SPAM]Re: [Plplot-devel] cmake error Qt build
>
>
>> On 2016-10-15 10:26-0700 Alan W. Irwin wrote:
>>
>>> Next Qt5 steps are for me to bump the minimum Qt5 version we support
>>> to 5.3.2 (which _might_ solve Pedros problem with the Qt5 version he
>>> is using), try out pyqt5, and completely change the method used to
>>> configure Qt5 to the most modern variant possible.  I suspect all
>>> target_link_libraries plain/keyword mixed signature issues will
>>> disappear with that change, and if so and also assuming pyqt5 works,
>>> then I _finally_ plan to remove the "experimental" description from
>>> the PLPLOT_USE_QT5 option, and turn on that option by default, which
>>> has been my goal for a very long time.
>>
>> Actually, I bumped to 5.3.1 for the reason given in the commit message
>> for 536f94b.  I also added some test infrastructure for pyqt5 with
>> good build and run-time results (commit 10fe84b).  So I have now
>> cleared out the easy Qt5 topics, and the only topic left for me on the
>> Qt5 agenda is the fairly difficult one of converting to the latest Qt5
>> support method.
>>
>>> So those interested in Qt5 should stay tuned....
>>
>> Same goes...
>>
>> @Pedro: could you try the latest git version of PLplot with your
>> plain/keyword target_link_libraries fixes only?  I am interested to
>> know whether the bump of the minimum acceptable Qt5 version from 5.2.0
>> to 5.3.1 solves your version consistency issue with a much later
>> version of Qt5, and that requested test should answer that question.
>> By the way, I also tried locally decrementing the minimum version to
>> 5.0.0 as an experiment, but that detected 5.3.2 (my system version of
>> Qt5) with no issues.  So I still don't understand why you were having
>> that version inconsistency issue when the minimum acceptable Qt5
>> version number was set to 5.2.0, but maybe setting it to 5.3.1 as in
>> the latest git master branch will solve that.
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> Astronomical research affiliation with Department of Physics and
>> Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca).
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __________________________
>>
>> Linux-powered Science
>> __________________________
>>
>


--------------------------------------------------------------------------------


> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot


--------------------------------------------------------------------------------


> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 

Re: [Plplot-devel] cmake error Qt build

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

Hi Pedro:

As of commit 018ed73, I have updated our build system to use the
latest CMake Qt5 support method.  There is still one
remaining issue which is the pkg-config files for Qt-related libraries
are configured incorrectly.  However, so long as you avoid pkg-config
(which I assume you do for your Windows Visual Studio IDE), this commit
should give you everything you need with no local workarounds necessary.

As you can tell from the commit message, I have comprehensively tested
this commit (except for the traditional (Makefile + pkg-config) build
system for the installed examples for obvious reasons) without finding
any Qt5 issues for PLplot on Linux.

So please test this commit (without local modifications) for your
Windows Visual Studio IDE platform, and let me know the results.

Meanwhile, I will be attempting to finish this Qt5 support method
update by figuring out a way to properly configure our pkg-config
files with this new CMake Qt5 support method.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] cmake error Qt build

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

On 2016-10-16 21:58-0400 Pedro Vicente wrote:

> Alan
>
> Some progress. Now the Qt project is generated

>From this good result it appears that the version incompatibility
issue you reported before has now disappeared which is a very
satisfying result.

[....]
> there are still 2 issues
>
>
> 1) Building the Visual Studio project, I get
>
> ========== Build: 16 succeeded, 72 failed, 0 up-to-date, 0 skipped ==========
>
> basically all the examples failed with link errors of the kind
>
> ------ Build started: Project: x13c, Configuration: Debug Win32 ------
> Building Custom Rule M:/plplot-plplot/examples/c/CMakeLists.txt
> CMake does not need to re-run because 
> M:\plplot-plplot\build\examples\c\CMakeFiles\generate.stamp is up-to-date.
> x13c.c
>    Creating library M:/plplot-plplot/build/examples/c/Debug/x13c.lib and 
> object M:/plplot-plplot/build/examples/c/Debug/x13c.exp
>
> Qt5Guid.lib(qfontengine.obj) : error LNK2019: unresolved external symbol 
> _hb_ot_tags_from_script referenced in function "public: bool __thiscall 
> QFontEngine::supportsScript(enum QChar::Script)const "
>
>
> But this might be because of the way I build Qt , so I'll try to debug this

OK, and good luck with that debugging.

>
> But regardelss of this, the examples should not be attempting to link with 
> the Qt libraries,
>
> for example, the list of libraries for the x13c project is
>
> kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib;..\..\src\Debug\plplot.lib;I:\qt-win32-msvc2015\lib\Qt5Svgd.lib;I:\qt-win32-msvc2015\lib\Qt5PrintSupportd.lib;I:\qt-win32-msvc2015\lib\Qt5Widgetsd.lib;I:\qt-win32-msvc2015\lib\Qt5Guid.lib;I:\qt-win32-msvc2015\lib\Qt5Cored.lib;C:\Program 
> Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86\Gdi32.Lib;C:\Program Files 
> (x86)\Windows 
> Kits\8.1\Lib\winv6.3\um\x86\ComDlg32.Lib;..\..\lib\csa\Debug\csirocsa.lib;..\..\lib\qsastime\Debug\qsastime.lib
>

That overlinking (which should basically be harmless, but it would be
nice to get rid of it, nevertheless) is exactly because of the
workaround you deployed above.  However, when you no longer need that
workaround (i.e., when I can update our build system to use the new
Qt5 support method) such overlinking should automatically be corrected.

In sum, I will consider my job done once I update our build system to
the latest Qt5 support method (and you confirm afterwards that that
updated version works for you without any workarounds and no
overlinking).  However, that build system update will take a while to
be completed because I am having trouble with the implementation.  I
have started a thread on the CMake mailing list concerning the issues
I have encountered, and we will see how it goes.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] cmake error Qt build

[Pedro V. <ped...@sp...>]

Alan

Some progress. Now the Qt project is generated



>> by dropping the PUBLIC keyword from the target_link_libraries command

I did

at line 318 of src/CMakeLists.txt I removed both the PUBLIC and PRIVATE 
words and added some messages like this


if(NON_TRANSITIVE)
  target_link_libraries(
    plplot
    ${libplplot_LINK_LIBRARIES}
    )
 MESSAGE( STATUS "if NON_TRANSITIVE:         " ${NON_TRANSITIVE} )
else(NON_TRANSITIVE)
  target_link_libraries(
    plplot
    ${libplplot_LINK_LIBRARIES}
    )
 MESSAGE( STATUS "else NON_TRANSITIVE:         " ${NON_TRANSITIVE} )
endif(NON_TRANSITIVE)


the ouput falls on the second case (else(NON_TRANSITIVE))

-- else NON_TRANSITIVE:         OFF

there are still 2 issues


1) Building the Visual Studio project, I get

========== Build: 16 succeeded, 72 failed, 0 up-to-date, 0 skipped 
==========

basically all the examples failed with link errors of the kind

------ Build started: Project: x13c, Configuration: Debug Win32 ------
  Building Custom Rule M:/plplot-plplot/examples/c/CMakeLists.txt
  CMake does not need to re-run because 
M:\plplot-plplot\build\examples\c\CMakeFiles\generate.stamp is up-to-date.
  x13c.c
     Creating library M:/plplot-plplot/build/examples/c/Debug/x13c.lib and 
object M:/plplot-plplot/build/examples/c/Debug/x13c.exp

Qt5Guid.lib(qfontengine.obj) : error LNK2019: unresolved external symbol 
_hb_ot_tags_from_script referenced in function "public: bool __thiscall 
QFontEngine::supportsScript(enum QChar::Script)const "


But this might be because of the way I build Qt , so I'll try to debug this

But regardelss of this, the examples should not be attempting to link with 
the Qt libraries,

for example, the list of libraries for the x13c project is

kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib;..\..\src\Debug\plplot.lib;I:\qt-win32-msvc2015\lib\Qt5Svgd.lib;I:\qt-win32-msvc2015\lib\Qt5PrintSupportd.lib;I:\qt-win32-msvc2015\lib\Qt5Widgetsd.lib;I:\qt-win32-msvc2015\lib\Qt5Guid.lib;I:\qt-win32-msvc2015\lib\Qt5Cored.lib;C:\Program 
Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86\Gdi32.Lib;C:\Program Files 
(x86)\Windows 
Kits\8.1\Lib\winv6.3\um\x86\ComDlg32.Lib;..\..\lib\csa\Debug\csirocsa.lib;..\..\lib\qsastime\Debug\qsastime.lib



2) the other issue is that the WxWidgets driver is not detected


Some time ago, I fixed that issue on the PLPlot version that was last 
released (not the git one) and posted here on this list the fix

but now with the git version,  is failing again, I'll go back and see what 
were the changes I made (adding the wxWidgets string corresponding to the 
latest "3.1.0" version
in some places)

-Pedro




----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>
Cc: "Hazen Babcock" <hba...@ma...>; "PLplot development list" 
<Plp...@li...>
Sent: Sunday, October 16, 2016 2:17 PM
Subject: Re: [Plplot-devel] cmake error Qt build


> Hi Pedro:
>
> On 2016-10-15 21:07-0400 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> Thank you for your effort in debuging this.
>> I send some results here attached , and I'll keep trying other options 
>> later.
>> by the way, wxWidgets is also not detected.
>>
>> I wonder, could this be a Windows only issue? Because you are trying on 
>> Linux, correct?
>
> Yes, all my tests are on Linux. Our goal is to tune our CMake-based
> build system so the Windows PLplot experience as just as smooth as on
> Linux, but we are not there yet, and your help in reporting any issues
> you find is important for helping us to reach that goal.  It turns out
> in this case, that the find Qt5 part of the issue is working smoothly
> on Windows.  That is, both your QTDIR and alternative
> CMAKE_PREFIX_PATH ways of setting up cmake appear to be giving you
> good Qt5_library_fullpath_list, etc., results.
>
>> also here
>>
>> https://www.kdab.com/using-cmake-with-qt-5/
>>
>> they specificaly say to *not* use the form
>>
>> find_package(Qt5
>>
>> but that is a resource from 2012, not sure if that is valid
>
> That resource is no longer valid.  Methods of finding Qt5 have been in a 
> big state of flux
> since those dark ages.
>
> [...]
>> first, the Qt location is detected
>>
>> -- Qt5_library_fullpath_list = 
>> I:/qt-win32-msvc2015/lib/Qt5Cored.lib;I:/qt-win32-msvc2015/lib/Qt5Guid.lib;I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib;I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib;I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
>> -- Qt5_library_LINK_FLAGS = I:/qt-win32-msvc2015/lib/Qt5Cored.lib 
>> I:/qt-win32-msvc2015/lib/Qt5Guid.lib 
>> I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib 
>> I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib 
>> I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
>>
>
> Those good results imply you are finding Qt5 successfully on your
> system (and see my comments above about that).  The remaining issues
> you have discovered are general Qt5 issues rather than Windows only.
>
>>
>>
>> but then the errors are
>>
>>
>> CMake Error at src/CMakeLists.txt:322 (target_link_libraries):
>> The plain signature for target_link_libraries has already been used with
>> the target "plplot".  All uses of target_link_libraries with a target 
>> must
>> be either all-keyword or all-plain.
>
> So after that Qt5 find succeeded, you ran into the same mixed
> plain/keyword target_link_libraries message you got before, and you
> have to locally fix that issue just like you did before by dropping
> the PUBLIC keyword from the target_link_libraries command indicated
> above.  The reason you are running into this is you are choosing to
> use static libraries, and if I did the same thing on Linux, I would
> also have to use that local workaround.  Once I get our build system
> changed so that it uses the modern Qt5 setup method, then I plan to
> comprehensively test both the shared (with and without dynamic
> devices) and static cases to confirm plain/keyword local workarounds
> are no longer necessary for any of the principal PLplot build
> configurations.
>
> Once you try the above local workaround, the important question is
> whether you still have the version inconsistency trouble that occurred
> for you before or whether the minimum version bump in the commit I did
> yesterday fixes that issue.  (And if it doesn't fix it, please bump
> the minimum version "5.3.1" that appears on line 80 of
> cmake/modules/qt.cmake to a minimum version that is consistent with
> your Qt5 version to see if that locally fixes the issue.)
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> 

Re: [Plplot-devel] cmake error Qt build

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

Hi Pedro:

On 2016-10-15 21:07-0400 Pedro Vicente wrote:

> Hi Alan
>
> Thank you for your effort in debuging this.
> I send some results here attached , and I'll keep trying other options later.
> by the way, wxWidgets is also not detected.
>
> I wonder, could this be a Windows only issue? Because you are trying on 
> Linux, correct?

Yes, all my tests are on Linux. Our goal is to tune our CMake-based
build system so the Windows PLplot experience as just as smooth as on
Linux, but we are not there yet, and your help in reporting any issues
you find is important for helping us to reach that goal.  It turns out
in this case, that the find Qt5 part of the issue is working smoothly
on Windows.  That is, both your QTDIR and alternative
CMAKE_PREFIX_PATH ways of setting up cmake appear to be giving you
good Qt5_library_fullpath_list, etc., results.

> also here
>
> https://www.kdab.com/using-cmake-with-qt-5/
>
> they specificaly say to *not* use the form
>
> find_package(Qt5
>
> but that is a resource from 2012, not sure if that is valid

That resource is no longer valid.  Methods of finding Qt5 have been in a big state of flux
since those dark ages.

[...]
> first, the Qt location is detected
>
> -- Qt5_library_fullpath_list = 
> I:/qt-win32-msvc2015/lib/Qt5Cored.lib;I:/qt-win32-msvc2015/lib/Qt5Guid.lib;I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib;I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib;I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
> -- Qt5_library_LINK_FLAGS = I:/qt-win32-msvc2015/lib/Qt5Cored.lib 
> I:/qt-win32-msvc2015/lib/Qt5Guid.lib 
> I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib 
> I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
>

Those good results imply you are finding Qt5 successfully on your
system (and see my comments above about that).  The remaining issues
you have discovered are general Qt5 issues rather than Windows only.

>
>
> but then the errors are
>
>
> CMake Error at src/CMakeLists.txt:322 (target_link_libraries):
> The plain signature for target_link_libraries has already been used with
> the target "plplot".  All uses of target_link_libraries with a target must
> be either all-keyword or all-plain.

So after that Qt5 find succeeded, you ran into the same mixed
plain/keyword target_link_libraries message you got before, and you
have to locally fix that issue just like you did before by dropping
the PUBLIC keyword from the target_link_libraries command indicated
above.  The reason you are running into this is you are choosing to
use static libraries, and if I did the same thing on Linux, I would
also have to use that local workaround.  Once I get our build system
changed so that it uses the modern Qt5 setup method, then I plan to
comprehensively test both the shared (with and without dynamic
devices) and static cases to confirm plain/keyword local workarounds
are no longer necessary for any of the principal PLplot build
configurations.

Once you try the above local workaround, the important question is
whether you still have the version inconsistency trouble that occurred
for you before or whether the minimum version bump in the commit I did
yesterday fixes that issue.  (And if it doesn't fix it, please bump
the minimum version "5.3.1" that appears on line 80 of
cmake/modules/qt.cmake to a minimum version that is consistent with
your Qt5 version to see if that locally fixes the issue.)

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] cmake error Qt build

[Pedro V. <ped...@sp...>]

Hi Alan

Thank you for your effort in debuging this.
I send some results here attached , and I'll keep trying other options 
later.
by the way, wxWidgets is also not detected.

I wonder, could this be a Windows only issue? Because you are trying on 
Linux, correct?

Tradionally I set the location of Qt with the environment
QTDIR=<path>
but I did some search on the detection of Qt by cmake on the official docs


http://doc.qt.io/qt-5/cmake-manual.html

and they say

"The easiest way to use CMake is to set the CMAKE_PREFIX_PATH environment 
variable to the install prefix of Qt 5."

so I tried that instead

also here

https://www.kdab.com/using-cmake-with-qt-5/

they specificaly say to *not* use the form

find_package(Qt5

but that is a resource from 2012, not sure if that is valid

I did

on Windows
git clone of plplot
using Visual Studio 2014
Qt 5.5.1 static build compiled by me
cmake 3.6.2
wxWidgets 3.1.0


cmake ".." -G "Visual Studio 
14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" 
 -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON 
 -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib 
 -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF 
 -DCMAKE_PREFIX_PATH:PATH=I:\qt-win32-msvc2015 -DPLPLOT_USE_QT5:BOOL=ON


I have some errors

first, the Qt location is detected

-- Qt5_library_fullpath_list = 
I:/qt-win32-msvc2015/lib/Qt5Cored.lib;I:/qt-win32-msvc2015/lib/Qt5Guid.lib;I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib;I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib;I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
-- Qt5_library_LINK_FLAGS = I:/qt-win32-msvc2015/lib/Qt5Cored.lib 
I:/qt-win32-msvc2015/lib/Qt5Guid.lib 
I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib 
I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib 
I:/qt-win32-msvc2015/lib/Qt5Svgd.lib



but then the errors are


CMake Error at src/CMakeLists.txt:322 (target_link_libraries):
  The plain signature for target_link_libraries has already been used with
  the target "plplot".  All uses of target_link_libraries with a target must
  be either all-keyword or all-plain.

  The uses of the plain signature are here:

   * I:/qt-win32-msvc2015/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:330 
(target_link_libraries)



libplplot_LINK_FLAGS = C:/Program Files (x86)/Windows 
Kits/8.1/Lib/winv6.3/um/x86/Gdi32.Lib;C:/Program Files (x86)/Windows 
Kits/8.1/Lib/winv6.3/um/x86/ComDlg32.Lib;-lcsirocsa;-lqsastime;I:/qt-win32-msvc2015/lib/Qt5Cored.lib 
I:/qt-win32-msvc2015/lib/Qt5Guid.lib 
I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib 
I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib 
I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
-- WARNING: Perl modules XML::Parser and/or XML::DOM not available
   so cannot check that swig_documentation.i is up to date.
CMake Error at bindings/qt_gui/CMakeLists.txt:57 (target_link_libraries):
  The plain signature for target_link_libraries has already been used with
  the target "plplotqt".  All uses of target_link_libraries with a target
  must be either all-keyword or all-plain.

  The uses of the plain signature are here:

   * I:/qt-win32-msvc2015/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:330 
(target_link_libraries)



-Pedro

----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Hazen Babcock" <hba...@ma...>; "Pedro Vicente" 
<ped...@sp...>
Cc: "PLplot development list" <Plp...@li...>
Sent: Saturday, October 15, 2016 6:50 PM
Subject: Re: [Plplot-devel] cmake error Qt build


> On 2016-10-15 10:26-0700 Alan W. Irwin wrote:
>
>> Next Qt5 steps are for me to bump the minimum Qt5 version we support
>> to 5.3.2 (which _might_ solve Pedros problem with the Qt5 version he
>> is using), try out pyqt5, and completely change the method used to
>> configure Qt5 to the most modern variant possible.  I suspect all
>> target_link_libraries plain/keyword mixed signature issues will
>> disappear with that change, and if so and also assuming pyqt5 works,
>> then I _finally_ plan to remove the "experimental" description from
>> the PLPLOT_USE_QT5 option, and turn on that option by default, which
>> has been my goal for a very long time.
>
> Actually, I bumped to 5.3.1 for the reason given in the commit message
> for 536f94b.  I also added some test infrastructure for pyqt5 with
> good build and run-time results (commit 10fe84b).  So I have now
> cleared out the easy Qt5 topics, and the only topic left for me on the
> Qt5 agenda is the fairly difficult one of converting to the latest Qt5
> support method.
>
>> So those interested in Qt5 should stay tuned....
>
> Same goes...
>
> @Pedro: could you try the latest git version of PLplot with your
> plain/keyword target_link_libraries fixes only?  I am interested to
> know whether the bump of the minimum acceptable Qt5 version from 5.2.0
> to 5.3.1 solves your version consistency issue with a much later
> version of Qt5, and that requested test should answer that question.
> By the way, I also tried locally decrementing the minimum version to
> 5.0.0 as an experiment, but that detected 5.3.2 (my system version of
> Qt5) with no issues.  So I still don't understand why you were having
> that version inconsistency issue when the minimum acceptable Qt5
> version number was set to 5.2.0, but maybe setting it to 5.3.1 as in
> the latest git master branch will solve that.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> 

Re: [Plplot-devel] cmake error Qt build

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

On 2016-10-15 10:26-0700 Alan W. Irwin wrote:

> Next Qt5 steps are for me to bump the minimum Qt5 version we support
> to 5.3.2 (which _might_ solve Pedros problem with the Qt5 version he
> is using), try out pyqt5, and completely change the method used to
> configure Qt5 to the most modern variant possible.  I suspect all
> target_link_libraries plain/keyword mixed signature issues will
> disappear with that change, and if so and also assuming pyqt5 works,
> then I _finally_ plan to remove the "experimental" description from
> the PLPLOT_USE_QT5 option, and turn on that option by default, which
> has been my goal for a very long time.

Actually, I bumped to 5.3.1 for the reason given in the commit message
for 536f94b.  I also added some test infrastructure for pyqt5 with
good build and run-time results (commit 10fe84b).  So I have now
cleared out the easy Qt5 topics, and the only topic left for me on the
Qt5 agenda is the fairly difficult one of converting to the latest Qt5
support method.

> So those interested in Qt5 should stay tuned....

Same goes...

@Pedro: could you try the latest git version of PLplot with your
plain/keyword target_link_libraries fixes only?  I am interested to
know whether the bump of the minimum acceptable Qt5 version from 5.2.0
to 5.3.1 solves your version consistency issue with a much later
version of Qt5, and that requested test should answer that question.
By the way, I also tried locally decrementing the minimum version to
5.0.0 as an experiment, but that detected 5.3.2 (my system version of
Qt5) with no issues.  So I still don't understand why you were having
that version inconsistency issue when the minimum acceptable Qt5
version number was set to 5.2.0, but maybe setting it to 5.3.1 as in
the latest git master branch will solve that.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] cmake error Qt build

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

On 2016-10-12 15:06-0700 Alan W. Irwin wrote:

> @Hazen and other Qt5 users here.  Once I move to the latest Qt5 cmake
> support methods, we will be on much less shaky ground with Qt5, but I
> will still consider our Qt5 support to be experimental because there
> are still text alignment issues which I have worked around with a
> semiempirical displacement of text compared to the Qt4 case.  See
> discussion in commentary of bindings/qt_gui/plqt.cpp concerning
> "Empirical Y offset".
>
> It's possible the issue is the default text alignment we are using for
> Qt5 is not correct, and we have to do some specific library startup
> for the Qt5 case to make its text alignment consistent with the Qt4
> text alignment.
>
> @Hazen: Would you be willing to look at this possibility?

Never mind concerning this text alignment question.  I discovered overnight that I
have always had access to the development version of Qt5 using Debian
Jessie, but the name of the packages has changed from the Qt4 versions
which is why I didn't find the Qt5 versions before this.

So once I installed the relevant packages I was able to configure
PLplot using -DPLPLOT_USE_QT5=ON, and build everything Qt related
without issues.

@Pedro: note I did not run into the issue you did concerning the Qt5
version.  But maybe that is because my system version of Qt5 (5.3.2)
is closer to the minimum version we currently express in the
find_package commands, 5.2.0.

@everybody:

I immediately noticed vertical alignment issues in the qt device
results for that configuration.  So I removed the vertical offset we
had used previously to compensate for known vertical alignment issues
with early versions of Qt5 (commit c58020c), and the result was
perfect vertical alignment for -dev qtwidget and -dev pdfqt, but still
not svgqt.  (For more details about the tests I ran concerning this,
see the commit message for c58020c.) So it appears all our alignment
troubles with Qt5 are in the process of disappearing as Qt5 alignment
bugs are fixed, and we have now finally been able to move to a version
of our code which does no vertical (or horizontal) alignment
adjustments for Qt5 to attempt to compensate for alignment bugs in
those libraries.  So I am extremely happy with this result as we
finally "get one foot on dry land".

Next Qt5 steps are for me to bump the minimum Qt5 version we support
to 5.3.2 (which _might_ solve Pedros problem with the Qt5 version he
is using), try out pyqt5, and completely change the method used to
configure Qt5 to the most modern variant possible.  I suspect all
target_link_libraries plain/keyword mixed signature issues will
disappear with that change, and if so and also assuming pyqt5 works,
then I _finally_ plan to remove the "experimental" description from
the PLPLOT_USE_QT5 option, and turn on that option by default, which
has been my goal for a very long time.

So those interested in Qt5 should stay tuned....

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] cmake error Qt build

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

On 2016-10-12 20:14-0400 Pedro Vicente wrote:

> Hi Alan
>
> some progress
>
> I removed the PRIVATE keyword from
>
> if(NON_TRANSITIVE)
>     target_link_libraries(plplotqt PRIVATE plplot ${MATH_LIB})
>
>
> and those errors went away

Hi Pedro:

Glad you found that workaround.

>
> However, now I get this one
>
> -- Found unsuitable Qt version "5.5.1" from 
> I:/qt-win32-msvc2015/bin/qmake.exe
>
> I do not find anywhere in the code where this message comes from 
> Cmake does generate a Visual Studio solution, but without the Qt files

Just a guess (see further discussion below), but try changing 5.2.0 to
5.5.1 in these two files:

./src/plplotConfig.cmake:  find_package(Qt5 5.2.0 COMPONENTS Svg Gui PrintSupport)
./cmake/modules/qt.cmake:    find_package(Qt5 5.2.0 COMPONENTS Svg Gui PrintSupport)

Now for that further discussion.  The CMake documentation for
find_package says this about that second (version) argument.

The `[version]` argument requests a version with which the package found
should be compatible [...]

I assume how that argument is interpreted is idiosyncratic to whatever
package is being found.  But in this Qt5 case I thought Qt5 versions
were always supposed to be backwards compatible with prior Qt5
versions.  That is, Qt developers are supposed to bump the major
number (5 for the Qt5 case) of their version triplet only for the
extremely rare case where they introduce backwards incompatibilities
(e.g., when they moved from Qt4 to Qt5 development). So from that
argument I would have thought 5.2.0 would cover _any_ Qt5 version of
5.2.0 or higher. So bumping that version argument to 5.5.1 as in my
guess above might make a difference, but I cannot see why.  So it is
unfortunately a case of try it and see....

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] cmake error Qt build

[Pedro V. <ped...@sp...>]

Hi Alan

some progress

I removed the PRIVATE keyword from

if(NON_TRANSITIVE)
      target_link_libraries(plplotqt PRIVATE plplot ${MATH_LIB})


and those errors went away

However, now I get this one

-- Found unsuitable Qt version "5.5.1" from 
I:/qt-win32-msvc2015/bin/qmake.exe

I do not find anywhere in the code where this message comes from 

Cmake does generate a Visual Studio solution, but without the Qt files

thanks

-Pedro


----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Hazen Babcock" <hba...@ma...>; "Pedro Vicente" 
<ped...@sp...>
Cc: "PLplot development list" <Plp...@li...>
Sent: Wednesday, October 12, 2016 6:06 PM
Subject: Re: [Plplot-devel] cmake error Qt build


> On 2016-10-12 09:03-0400 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> yes, that was what I did,  a clone of the git master from
>>
>>
>> https://sourceforge.net/p/plplot/plplot/ci/master/tree/
>>
>> I'll try again later today
>
> Hi Pedro:
>
> I have put this discussion back on the plplot-devel list since I
> assume the Qt5 users like Hazen that are lurking there will be
> interested.
>
> I now realize that a similar issue has come up before (look for the
> subject line of "Qt5 / cmake error" in January this year in the
> plplot-devel archive).  Hazen's workaround was to drop the offending
> PRIVATE keyword from the target_link_libraries command in his commit
> 5d27ac4. What is new in your case is you are using static libraries so
> it is a different target_link_libraries command where the issue
> occurs.  So I suggest you try a similar workaround (remove either the
> PRIVATE or PUBLIC keyword from the command) for the offending PLplot
> target_link_libraries command reported in your error message.
>
> Note a more fundamental fix for this issue of mixing of plain and
> keyword signatures for the target_link_libraries commands is to
> complete reimplement how we support Qt5 in our build system.  The
> issue is Qt5 supports ~5 different ways of building Qt5-using
> libraries, and we currently use one of the oldest of those methods
> (suitable for CMake-2) which uses the plain target_link_libraries
> signature and which therefore does not work with our keyworded version
> of the same command. But our minimum CMake version is now in the
> CMake-3 range which allows us to move to the most modern method
> supported by Qt5.  So once I do that, I think this mixed plain and
> keyword issue will simply disappear, and I will be able to reverse
> Hazen's workaround.  But I am not sure I can deal
> with this before the release of PLplot-5.12.0 so for now you have to
> use workarounds for Qt5 (which is still only experimentally supported
> by PLplot, after all, with Qt4 being the tried and true library that
> we still recommend to our users).
>
> @Hazen and other Qt5 users here.  Once I move to the latest Qt5 cmake
> support methods, we will be on much less shaky ground with Qt5, but I
> will still consider our Qt5 support to be experimental because there
> are still text alignment issues which I have worked around with a
> semiempirical displacement of text compared to the Qt4 case.  See
> discussion in commentary of bindings/qt_gui/plqt.cpp concerning
> "Empirical Y offset".
>
> It's possible the issue is the default text alignment we are using for
> Qt5 is not correct, and we have to do some specific library startup
> for the Qt5 case to make its text alignment consistent with the Qt4
> text alignment.
>
> @Hazen: Would you be willing to look at this possibility?
>
> Of course, we could also just be up against a Qt5 text alignment bug
> which means if/when Qt5 fixed that hypothesized bug, our semiempirical
> text displacement would have to be adjusted to zero to compensate. So
> this is a strong possibility to look at if Qt5 users find that text
> alignment is suddenly poor when they upgrade their Qt5 version.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> 

Re: [Plplot-devel] cmake error Qt build

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

On 2016-10-12 09:03-0400 Pedro Vicente wrote:

> Hi Alan
>
> yes, that was what I did,  a clone of the git master from
>
>
> https://sourceforge.net/p/plplot/plplot/ci/master/tree/
>
> I'll try again later today

Hi Pedro:

I have put this discussion back on the plplot-devel list since I
assume the Qt5 users like Hazen that are lurking there will be
interested.

I now realize that a similar issue has come up before (look for the
subject line of "Qt5 / cmake error" in January this year in the
plplot-devel archive).  Hazen's workaround was to drop the offending
PRIVATE keyword from the target_link_libraries command in his commit
5d27ac4. What is new in your case is you are using static libraries so
it is a different target_link_libraries command where the issue
occurs.  So I suggest you try a similar workaround (remove either the
PRIVATE or PUBLIC keyword from the command) for the offending PLplot
target_link_libraries command reported in your error message.

Note a more fundamental fix for this issue of mixing of plain and
keyword signatures for the target_link_libraries commands is to
complete reimplement how we support Qt5 in our build system.  The
issue is Qt5 supports ~5 different ways of building Qt5-using
libraries, and we currently use one of the oldest of those methods
(suitable for CMake-2) which uses the plain target_link_libraries
signature and which therefore does not work with our keyworded version
of the same command. But our minimum CMake version is now in the
CMake-3 range which allows us to move to the most modern method
supported by Qt5.  So once I do that, I think this mixed plain and
keyword issue will simply disappear, and I will be able to reverse
Hazen's workaround.  But I am not sure I can deal
with this before the release of PLplot-5.12.0 so for now you have to
use workarounds for Qt5 (which is still only experimentally supported
by PLplot, after all, with Qt4 being the tried and true library that
we still recommend to our users).

@Hazen and other Qt5 users here.  Once I move to the latest Qt5 cmake
support methods, we will be on much less shaky ground with Qt5, but I
will still consider our Qt5 support to be experimental because there
are still text alignment issues which I have worked around with a
semiempirical displacement of text compared to the Qt4 case.  See
discussion in commentary of bindings/qt_gui/plqt.cpp concerning
"Empirical Y offset".

It's possible the issue is the default text alignment we are using for
Qt5 is not correct, and we have to do some specific library startup
for the Qt5 case to make its text alignment consistent with the Qt4
text alignment.

@Hazen: Would you be willing to look at this possibility?

Of course, we could also just be up against a Qt5 text alignment bug
which means if/when Qt5 fixed that hypothesized bug, our semiempirical
text displacement would have to be adjusted to zero to compensate. So
this is a strong possibility to look at if Qt5 users find that text
alignment is suddenly poor when they upgrade their Qt5 version.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] build with wxWidgets, Visual Studio

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

On 2016-10-11 23:31-0400 Pedro Vicente wrote:

> Hi Alan
>
>> I have just looked at the latest official version of
>> FindwxWidgets.cmake from the cmake git master branch and it is the
>> same as or superior to the PLplot unofficial version in all respects
>> (e.g., in supporting all the recently released versions of wxWidgets).
>> Therefore, I have just changed the PLplot master branch so that our
>> unofficial version follows the official version (see my recent commit
>> 511a6ac).
>
>
> About that cmake wxWidgets driver bug that I reported here and patched on my 
> local plplot 5.11.1 version
>
> I did a clone of the git master from
>
>
> https://sourceforge.net/p/plplot/plplot/ci/master/tree/
>
> and I do get an error, that wxWidgets cannot be found

Hi Pedro:

Thanks for following up on my request to test our latest git version of
cmake/modules/FindwxWidgets.cmake.  Since that file still doesn't work to allow
you to find wxWidgets-3.1.0 for your particular platform circumstances,
I strongly suggest you do the following to debug this issue further:

To simplify (always a good thing when debugging), please try a simple
CMake test project that attempts only to find wxWidgets using the
official CMake find module from whatever version of cmake you are
using. I have attached a compressed version of such a test project.
It gives me the following results here for CMake-3.5.2:

-- Found wxWidgets: -L/usr/lib/x86_64-linux-gnu;-pthread;;;-lwx_baseu-3.0;-lwx_gtk2u_core-3.0 (found version "3.0.2") 
-- wxWidgets_FOUND           : TRUE
-- wxWidgets_INCLUDE_DIRS    : /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0;/usr/include/wx-3.0
-- wxWidgets_LIBRARY_DIRS    : /usr/lib/x86_64-linux-gnu
-- wxWidgets_LIBRARIES       : -L/usr/lib/x86_64-linux-gnu;-pthread;;;-lwx_baseu-3.0;-lwx_gtk2u_core-3.0
-- wxWidgets_CXX_FLAGS       : -pthread
-- wxWidgets_USE_FILE        : /home/software/cmake/install-3.5.2/share/cmake-3.5/Modules/UsewxWidgets.cmake
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/build_dir

I have just checked the official find modules for wxwidgets, and the
big change from CMake-3.6.2 to 3.7.0-rc1 was to introduce the changes
required to find wxWidgets-3.1.0.  So the attached test project should
fail to find wxWidgets-3.1.0 if you are using CMake-3.6.2 or any prior
version, but if you try it with CMake-3.7.0-rc1, it should succeed
unless there is a bug in that official version (which is effectively
the same as the PLplot version so I suspect there is a bug in that
version).  If you pass on to me the changes in the CMake-3.7.0-rc1
find module (normally found in
$PREFIX/share/cmake-3.7/Modules/FindwxWidgets.cmake for
CMake-3.7.0-rc1) that makes it work for this simple test case, then I
will update the PLplot version of the file accordingly, and also
request the CMake developers make your suggested change.  This is
excellent timing for making such a bugfix suggestion to them since
3.7.0 has not yet been officially released.

Of course, on the other hand, if the simple test project succeeds with
finding wxwidgets-3.1.0 on your platform with CMake-3.7.0-rc1, then
the problem is a PLplot bug rather than a simple CMake find module
bug, and we will have to dig deeper.  So please keep in touch
about your results for the suggested simple test.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] cmake error Qt build

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

On 2016-10-11 22:08-0400 Pedro Vicente wrote:

> Hi
>
> I get an error build with Qt driver, the call and error are below
> CMake Error at src/CMakeLists.txt:314 (target_link_libraries):
>  The plain signature for target_link_libraries has already been used with
>  the target "plplot".  All uses of target_link_libraries with a target must
>  be either all-keyword or all-plain.
[...]

Hi Pedro:

I am pretty sure we have solved this issue already, but could you
please check by trying the same test with the git master branch
version?

Thanks.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] [Plplot-general] cmake error Qt build

[Pedro V. <ped...@sp...>]

one detail

I am using a statically built Qt version

this can be done with

git clone https://code.qt.io/qt/qt5.git qt-everywhere-opensource-src-5.5.1
cd qt-everywhere-opensource-src-5.5.1
git checkout 5.5
perl init-repository --module-subset=qtbase,qtimageformats,-qtwebkit,-qtwebkit-examples,-qtwebengine
git checkout v5.5.1
cd qtimageformats && git checkout v5.5.1 && cd ..

configure -prefix I:/qt-win32-msvc2015 -debug -static -static-runtime -platform win32-msvc2015 -confirm-license -nomake examples -no-compile-examples -nomake tests -no-opengl 
jom -j 4
nmake install


also these changes have to be made  for msvc-desktop.conf

QMAKE_CFLAGS_DEBUG      = -Zi -MTd
QMAKE_CFLAGS_RELEASE    = -O2 -MT






  ----- Original Message ----- 
  From: Pedro Vicente 
  To: plp...@li... ; plp...@li... 
  Sent: Tuesday, October 11, 2016 10:08 PM
  Subject: [Plplot-general] cmake error Qt build


  Hi

  I get an error build with Qt driver, the call and error are below 


  The home page documenation seems not to have much information about all the cmake options .
  this is probably the most complex cmake build system I have ever found, and without documenation makes it difficult to use.
  Would it be possible to add some simple usage ?

  thanks

  using 
  Windows Visual Studio 2015
  Qt version 5.5.1
  PLpot version 5.11.1

  call used:


  cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF -DANY_QT_DEVICE:BOOL=ON -DPLPLOT_USE_QT5:BOOL=ON -DPLPLOT_USE_QT5=ON -DDEFAULT_ALL_DEVICES=ON


  relevant output relevant to Qt and error seems to be


  DEFAULT_NO_BINDINGS=OFF
  ENABLE_qt=
  PLPLOT_USE_QT5=ON
  ENABLE_pyqt4=
  -- Attempting to use Qt5 so have set PLD_epsqt to OFF since Qt5 does not support PostScript
  PLPLOT_USE_QT5=ON
  -- Qt5_library_fullpath_list = I:/qt-win32-msvc2015/lib/Qt5Cored.lib;I:/qt-win32-msvc2015/lib/Qt5Guid.lib;I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib;I:/qt
  -win32-msvc2015/lib/Qt5Widgetsd.lib;I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
  -- Qt5_library_LINK_FLAGS = I:/qt-win32-msvc2015/lib/Qt5Cored.lib I:/qt-win32-msvc2015/lib/Qt5Guid.lib I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib I:/qt-wi
  n32-msvc2015/lib/Qt5Widgetsd.lib I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
  ANY_QT_DEVICE=ON
  -- WARNING: ENABLE_python is OFF so setting ENABLE_pyqt4 to OFF.


  CMake Error at src/CMakeLists.txt:314 (target_link_libraries):
    The plain signature for target_link_libraries has already been used with
    the target "plplot".  All uses of target_link_libraries with a target must
    be either all-keyword or all-plain.

    The uses of the plain signature are here:

     * I:/qt-win32-msvc2015/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:330 (target_link_libraries)



  libplplot_LINK_FLAGS = C:/Program Files (x86)/Windows Kits/8.1/Lib/winv6.3/um/x86/Gdi32.Lib;C:/Program Files (x86)/Windows Kits/8.1/Lib/winv6.3/um/x86/ComDlg
  32.Lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxbase31ud.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxmsw31ud_core.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxpngd.lib;M:/wx/
  wxwidgets-3.1.0/lib/vc_lib/wxtiffd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxjpegd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxzlibd.lib;M:/wx/wxwidgets-3.1.0/lib/vc
  _lib/wxregexud.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxexpatd.lib;winmm;comctl32;rpcrt4;wsock32;-lcsirocsa;-lnistcd;-lqsastime;I:/qt-win32-msvc2015/lib/Qt5Cor
  ed.lib I:/qt-win32-msvc2015/lib/Qt5Guid.lib I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib I:/qt-win32-msvc2015/lib/Q
  t5Svgd.lib
  -- WARNING: Perl modules XML::Parser and/or XML::DOM not available
     so cannot check that swig_documentation.i is up to date.
  CMake Error at bindings/qt_gui/CMakeLists.txt:56 (target_link_libraries):
    The plain signature for target_link_libraries has already been used with
    the target "plplotqt".  All uses of target_link_libraries with a target
    must be either all-keyword or all-plain.

    The uses of the plain signature are here:

     * I:/qt-win32-msvc2015/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:330 (target_link_libraries)



  ----------------------
  Pedro Vicente
  ped...@sp...
  http://www.space-research.org/


------------------------------------------------------------------------------


  ------------------------------------------------------------------------------
  Check out the vibrant tech community on one of the world's most 
  engaging tech sites, SlashDot.org! http://sdm.link/slashdot


------------------------------------------------------------------------------


  _______________________________________________
  Plplot-general mailing list
  Plp...@li...
  https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-devel] build with wxWidgets, Visual Studio

[Pedro V. <ped...@sp...>]

Hi Alan

> I have just looked at the latest official version of
> FindwxWidgets.cmake from the cmake git master branch and it is the
> same as or superior to the PLplot unofficial version in all respects
> (e.g., in supporting all the recently released versions of wxWidgets).
> Therefore, I have just changed the PLplot master branch so that our
> unofficial version follows the official version (see my recent commit
> 511a6ac).


About that cmake wxWidgets driver bug that I reported here and patched on my 
local plplot 5.11.1 version

I did a clone of the git master from


https://sourceforge.net/p/plplot/plplot/ci/master/tree/

and I do get an error, that wxWidgets cannot be found


i do keep my own svn repositories with code that I use, and it seems that 
the differences I did are:

(sorry about the confusing output below, this is a copy of a trac web 
output)

the numbers at right are line numbers of file

plplot-5.11.1/cmake/modules/FindwxWidgets.cmake (2 diffs)

for revisions 1 and 3 of that file

plplot-5.11.1/cmake/modules/FindwxWidgets.cmake
r1  r3
193 193 # two versions for controlling how verbose your output should be.
194 194 macro(DBG_MSG _MSG)
195   # message(STATUS
196   #    "${CMAKE_CURRENT_LIST_FILE}(${CMAKE_CURRENT_LIST_LINE}): 
${_MSG}")
  195 message(STATUS
  196     "${CMAKE_CURRENT_LIST_FILE}(${CMAKE_CURRENT_LIST_LINE}): ${_MSG}")
197 197 endmacro()
198 198 macro(DBG_MSG_V _MSG)
199   #  message(STATUS
200   #    "${CMAKE_CURRENT_LIST_FILE}(${CMAKE_CURRENT_LIST_LINE}): 
${_MSG}")
  199   message(STATUS
  200     "${CMAKE_CURRENT_LIST_FILE}(${CMAKE_CURRENT_LIST_LINE}): ${_MSG}")
201 201 endmacro()
202 202
.  .
480 480       ENV ProgramFiles
481 481     PATH_SUFFIXES
  482           wxWidgets-3.1.0
482 483       wxWidgets-3.0.2
483 484       wxWidgets-3.0.1



so, my fix here was to add

wxWidgets-3.1.0


at line 482 of that file


also here was just to add the "31" version like the others are


plplot-5.11.1/cmake/modules/FindwxWidgets.cmake
r3  r5
278 278     list(APPEND wxWidgets_FIND_COMPONENTS
279 279       ${wxWidgets_COMMON_LIBRARIES})
  280         DBG_MSG("wxWidgets_COMMON_LIBRARIES : 
${wxWidgets_COMMON_LIBRARIES}")
280 281   endif()
281 282
.  .
322 323     find_library(WX_base${_DBG}
323 324       NAMES
  325           wxbase31${_UCD}${_DBG}
324 326       wxbase30${_UCD}${_DBG}
325 327       wxbase29${_UCD}${_DBG}
.  .
335 337       find_library(WX_${LIB}${_DBG}
336 338         NAMES
  339                 wxbase31${_UCD}${_DBG}_${LIB}
337 340         wxbase30${_UCD}${_DBG}_${LIB}
338 341         wxbase29${_UCD}${_DBG}_${LIB}
.  .
350 353     find_library(WX_mono${_DBG}
351 354       NAMES
  355           wxmsw${_UNV}31${_UCD}${_DBG}
352 356       wxmsw${_UNV}30${_UCD}${_DBG}
353 357       wxmsw${_UNV}29${_UCD}${_DBG}
.  .
366 370       find_library(WX_${LIB}${_DBG}
367 371         NAMES
368           wxmsw${_UNV}30${_UCD}${_DBG}_${LIB}
  372         wxmsw${_UNV}31${_UCD}${_DBG}_${LIB}
  373                 wxmsw${_UNV}30${_UCD}${_DBG}_${LIB}
369 374         wxmsw${_UNV}29${_UCD}${_DBG}_${LIB}
370 375         wxmsw${_UNV}28${_UCD}${_DBG}_${LIB}



----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Laurent Berger" <lau...@un...>
Cc: <plp...@li...>
Sent: Saturday, September 17, 2016 2:53 PM
Subject: Re: [Plplot-devel] build with wxWidgets, Visual Studio


> On 2016-09-17 09:12+0200 Laurent Berger wrote:
>
>> Hi Pedro,
>>
>> I am using vs2013 and plplot (from github) with wxwidgets and I haven't 
>> got
>> any problem. I think you should update findwxwidgets.cmake from
>> https://sourceforge.net/p/plplot/plplot/ci/master/tree/cmake/modules/FindwxWidgets.cmake
>> (see
>> https://sourceforge.net/p/plplot/plplot/ci/5b9dd303b50061c8ed3a9f149aea4b2a6817eece/log/?path=/cmake/modules/FindwxWidgets.cmake)
>>
>> May be you should clone plplot version but it is a develloper version.
>>
>> I hope it will solve your problem.
>>
>> Laurent
>
> I have just looked at the latest official version of
> FindwxWidgets.cmake from the cmake git master branch and it is the
> same as or superior to the PLplot unofficial version in all respects
> (e.g., in supporting all the recently released versions of wxWidgets).
> Therefore, I have just changed the PLplot master branch so that our
> unofficial version follows the official version (see my recent commit
> 511a6ac).
>
> @Pedro, Laurent, and other wxwidgets users:
> Please test the latest PLplot git master branch to make sure that
> unofficial FindwxWidgets.cmake find module satisfies your needs.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 

[Plplot-devel] cmake error Qt build

[Pedro V. <ped...@sp...>]

Hi

I get an error build with Qt driver, the call and error are below 


The home page documenation seems not to have much information about all the cmake options .
this is probably the most complex cmake build system I have ever found, and without documenation makes it difficult to use.
Would it be possible to add some simple usage ?

thanks

using 
Windows Visual Studio 2015
Qt version 5.5.1
PLpot version 5.11.1

call used:


cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF -DANY_QT_DEVICE:BOOL=ON -DPLPLOT_USE_QT5:BOOL=ON -DPLPLOT_USE_QT5=ON -DDEFAULT_ALL_DEVICES=ON


relevant output relevant to Qt and error seems to be


DEFAULT_NO_BINDINGS=OFF
ENABLE_qt=
PLPLOT_USE_QT5=ON
ENABLE_pyqt4=
-- Attempting to use Qt5 so have set PLD_epsqt to OFF since Qt5 does not support PostScript
PLPLOT_USE_QT5=ON
-- Qt5_library_fullpath_list = I:/qt-win32-msvc2015/lib/Qt5Cored.lib;I:/qt-win32-msvc2015/lib/Qt5Guid.lib;I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib;I:/qt
-win32-msvc2015/lib/Qt5Widgetsd.lib;I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
-- Qt5_library_LINK_FLAGS = I:/qt-win32-msvc2015/lib/Qt5Cored.lib I:/qt-win32-msvc2015/lib/Qt5Guid.lib I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib I:/qt-wi
n32-msvc2015/lib/Qt5Widgetsd.lib I:/qt-win32-msvc2015/lib/Qt5Svgd.lib
ANY_QT_DEVICE=ON
-- WARNING: ENABLE_python is OFF so setting ENABLE_pyqt4 to OFF.


CMake Error at src/CMakeLists.txt:314 (target_link_libraries):
  The plain signature for target_link_libraries has already been used with
  the target "plplot".  All uses of target_link_libraries with a target must
  be either all-keyword or all-plain.

  The uses of the plain signature are here:

   * I:/qt-win32-msvc2015/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:330 (target_link_libraries)



libplplot_LINK_FLAGS = C:/Program Files (x86)/Windows Kits/8.1/Lib/winv6.3/um/x86/Gdi32.Lib;C:/Program Files (x86)/Windows Kits/8.1/Lib/winv6.3/um/x86/ComDlg
32.Lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxbase31ud.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxmsw31ud_core.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxpngd.lib;M:/wx/
wxwidgets-3.1.0/lib/vc_lib/wxtiffd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxjpegd.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxzlibd.lib;M:/wx/wxwidgets-3.1.0/lib/vc
_lib/wxregexud.lib;M:/wx/wxwidgets-3.1.0/lib/vc_lib/wxexpatd.lib;winmm;comctl32;rpcrt4;wsock32;-lcsirocsa;-lnistcd;-lqsastime;I:/qt-win32-msvc2015/lib/Qt5Cor
ed.lib I:/qt-win32-msvc2015/lib/Qt5Guid.lib I:/qt-win32-msvc2015/lib/Qt5PrintSupportd.lib I:/qt-win32-msvc2015/lib/Qt5Widgetsd.lib I:/qt-win32-msvc2015/lib/Q
t5Svgd.lib
-- WARNING: Perl modules XML::Parser and/or XML::DOM not available
   so cannot check that swig_documentation.i is up to date.
CMake Error at bindings/qt_gui/CMakeLists.txt:56 (target_link_libraries):
  The plain signature for target_link_libraries has already been used with
  the target "plplotqt".  All uses of target_link_libraries with a target
  must be either all-keyword or all-plain.

  The uses of the plain signature are here:

   * I:/qt-win32-msvc2015/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:330 (target_link_libraries)



----------------------
Pedro Vicente
ped...@sp...
http://www.space-research.org/

Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change thedefault blackbackground

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

Hi Pedro
Glad you have things working. I believe Alan is close to having a new
release of Plplot so I'm not sure if now is a suitable time to
introduce new features, but I will add overloads of the Create
function to my to do list for early in the next release cycle.

Regarding the old version. There are very significant behind the
scenes changes to help with code management. The old device is no
longer being actively worked on. The driver for putting things in a
template is that it means that you can have a plplot window based on
any kind of wxWindow. Of course most often we create a wxPanel, but
the example uses a wxFrame as does your code and if you really wanted
you could create a wxPLplotwindow<wxButton> or if someone in the
future generated a wxAcceleratedGraphicsWindow that used OpenGL then I
guess that could be rendered to as well - or at least it wouldn't mean
an API change to make use of it.

Phil

On 9 October 2016 at 06:19, Pedro Vicente
<ped...@sp...> wrote:
> Hi Phil
>
>> Traditionally colour 0 has always been the background colour, so
>> plscol0 passing in colour 0 is the same as plscolbg. You should use
>> plcol(1) or upwards for rendering.
>
>
> ok, I understand now, it seems it was just me trying to redefine color index
> 0 2 times , and there is no need to
>
> this code worked for me (white background with color 0, black plot with
> color 1)
>
> bool wxAppPlot::OnInit()
> {
>  wx_PLplotwindow<wxFrame> *frame = new wx_PLplotwindow<wxFrame>();
>  frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>    wxDefaultPosition,
>    wxSize(900, 700));
>  frame->Show();
>
>  wx_PLplotstream* pls = frame->GetStream();
>  pls->init();
>
>  pls->adv(0);
>  pls->scol0(0, 255, 255, 255);
>  pls->clear();
>  pls->scol0(1, 0, 0, 0);
>
>  //render
>
>  plot_window(frame);
>  return true;
> }
>
> Note here that I am using my modified version "wx_PLplotstream" that does
> not call
> init();
>
> but I am calling init(); right at start , so this is the same I think of
> using the regular class "wxPLplotstream"
>
> so, my confusion came because I was convinced that to modify the background,
> this had to be done *before* calling
> init();
>
> but it seems we don't have to do it that way, is that right ?
>
> the documenation says that it is needed
>
> http://plplot.sourceforge.net/docbook-manual/plplot-html-5.11.1/color.html
>
> "There are a number of options for changing the default red on black colors.
> The user may set the index 0 background color using the command-line bg
> parameter or by calling plscolbg (or plscol0 with a 0 index) before plinit.
> During the course of the plot, the user can change the foreground color as
> often as desired using plcol0 to select the index of the desired color. "
>
> or is just this sequence of calls that makes it not necessary to do it
> before init() ?
>
> pls->adv(0);
>  pls->scol0(0, 255, 255, 255);
>  pls->clear();
>  pls->scol0(1, 0, 0, 0);
>
>
>> I don't think I can or should remove the plinit call in
>> wxPLstream::Create because I think that has been there a long time and
>> would break other users' existing code.
>
>
> ok, understood, that makes sense , yes
>
>> However I could overload the
>> Create function so that it accepts some extra initialisation variables
>> such as background colour.
>
>
>
> that would be a must have if the only way to change the background was to do
> it before init()
> but since it seems that is not needed so not really a must have
>
> but maybe there are other things that can only be done before  init()
>
> by the way, I have a small request , is that possible to keep the
> "deprecated" wxWidgets classes around?
>
> it seems the only difference is that new wxWidgets is the use of templates
> as in
>
> template< class WXWINDOW >
> void plot_window(wx_PLplotwindow<WXWINDOW> *plotwindow);
>
> my experience with templates is that they make the code more difficult to
> track and find bugs
>
> Maybe merge the "deprecated" wxWidgets and the new one just into one file or
> class and give the option to use either one (don't know
> if this makes sense)
>
>
>
> -Pedro
>
>
>
> ----- Original Message ----- From: "Phil Rosenberg"
> <p.d...@gm...>
> To: "Pedro Vicente" <ped...@sp...>
> Cc: <plp...@li...>;
> <plp...@li...>
> Sent: Friday, October 07, 2016 7:51 AM
>
> Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change
> thedefault blackbackground
>
>
>> Hi Pedro
>> Traditionally colour 0 has always been the background colour, so
>> plscol0 passing in colour 0 is the same as plscolbg. You should use
>> plcol(1) or upwards for rendering. In some ways it is up to you how
>> you do that. You can either set up you pallet at the beginning using
>> plscol0 or plscsol0a then use plcol0(1), plcol0(2) etc, or you can
>> just always use plscol0(1), but use repeated calls to plscol0 or
>> plscol0a to keep changing colour 1.
>>
>> Do you happen to call plenv() after setting colour 0 to black again? I
>> have a feeling that plenv() may clear the page again. But I'm not
>> sure. If you are still haing problems using colours 1 and above for
>> drawing then let us know and I'll have a further look.
>>
>> I don't think I can or should remove the plinit call in
>> wxPLstream::Create because I think that has been there a long time and
>> would break other users' existing code. However I could overload the
>> Create function so that it accepts some extra initialisation variables
>> such as background colour.
>>
>> Phil
>>
>> On 6 October 2016 at 16:41, Pedro Vicente
>> <ped...@sp...> wrote:
>>>
>>> Phil
>>>
>>>
>>> I believe there is stiil an issue with this solution
>>>
>>> my sample worked because I had
>>>
>>> plcol0(8);
>>>
>>> that does the plot in brown color
>>>
>>> if I try to plot in black color (on white bacground now) by doing
>>>
>>> plcol0(0);
>>>
>>> then I have no plot, since color 0 is now white
>>>
>>> is there a way with this solution to define color 0 as black for the
>>> plot?
>>>
>>> I tried to call
>>>
>>> plscol0(0, 0, 0, 0);
>>>
>>> as
>>>
>>> wxPLplotstream* pls = plotwindow->GetStream();
>>>  pls->adv(0);
>>>  pls->scolbg(255, 255, 255);
>>>  pls->clear();
>>>  plscol0(0, 0, 0, 0);
>>>
>>> but like this I have the default red on black again
>>>
>>>
>>> for now, the way I was able to have the black on white background was to
>>> replicate all the code
>>> of
>>> wxPLplotwindow
>>> wxPLplotwindow
>>>
>>> into new classes , giving them another name, commenting the init() call
>>> on
>>> them and then
>>> doing this code (note that the classes are renamed to wx_PLplotwindow and
>>> wx_PLplotstream)
>>>
>>>
>>>
>>>
>>> bool wxAppPlot::OnInit()
>>> {
>>>  wx_PLplotwindow<wxFrame> *frame = new wx_PLplotwindow<wxFrame>();
>>>  frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>>>    wxDefaultPosition,
>>>    wxSize(900, 700));
>>>  frame->Show();
>>>
>>>  //set background color (0) to white RGB(255,255,255)
>>>  //must be called before plinit()
>>>  plscolbg(255, 255, 255);
>>>
>>>  wx_PLplotstream* pls = frame->GetStream();
>>>  pls->init();
>>>
>>>  //change color (0) to black RGB(0, 0, 0)
>>>  //must be called after plinit()
>>>  plscol0(0, 0, 0, 0);
>>>
>>>  Plot(frame);
>>>  return true;
>>> }
>>>
>>>
>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>> //Plot
>>>
>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>
>>> template< class WXWINDOW >
>>> void Plot(wx_PLplotwindow<WXWINDOW> *plotwindow)
>>> {
>>>  wx_PLplotstream* pls = plotwindow->GetStream();
>>>
>>>  //render
>>>  const int NSIZE = 101;
>>>  PLFLT x[NSIZE], y[NSIZE];
>>>  PLFLT xmin = 0, xmax = 100, ymin = 0, ymax = 10;
>>>
>>>  for (int i = 0; i < NSIZE; i++)
>>>  {
>>>    x[i] = i;
>>>    y[i] = 5;
>>>  }
>>>
>>>  plschr(0, 1.0);
>>>  plcol0(0);
>>>  plenv(xmin, xmax, ymin, ymax, 0, 0);
>>>  pllab("x", "y", "Label");
>>>  plpoin(NSIZE, x, y, 46);
>>>
>>>  plotwindow->RenewPlot();
>>> }
>>>
>>>
>>>
>>>
>>> ----- Original Message ----- From: "Pedro Vicente"
>>> <ped...@sp...>
>>> To: "Phil Rosenberg" <p.d...@gm...>
>>> Cc: <plp...@li...>;
>>> <plp...@li...>
>>> Sent: Thursday, October 06, 2016 10:44 AM
>>>
>>> Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change
>>> thedefault blackbackground
>>>
>>>
>>>> Hi Phil, Alan
>>>>
>>>> This solution worked for me, thanks
>>>>
>>>>
>>>>> The easiest way to do this at the moment is something like
>>>>>
>>>>> wxPLplotstream* pls = plotwindow->GetStream();
>>>>> pls->adv( 0 );
>>>>> pls->scolbg(255, 255, 255);
>>>>> pls->clear();
>>>>> //rest of your plotting code
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I'm very open to better ways
>>>>> to do this if you have suggestions.
>>>>
>>>>
>>>>
>>>> The only suggestion I have is the one I sent on my previous mail, that
>>>> was *not* to have
>>>>
>>>> wxPLplotstream::Create
>>>>
>>>> call
>>>>
>>>> init()
>>>>
>>>> and let the user do that on his application.
>>>>
>>>>
>>>> By looking at the samples, I believe they all call plinit() at start,
>>>>
>>>>
>>>>
>>>> my complete test code is now
>>>>
>>>>
>>>> #include "wx/wxprec.h"
>>>> #include "wx/wx.h"
>>>> #include "wxPLplotwindow.h"
>>>>
>>>> template< class WXWINDOW >
>>>> void Plot(wxPLplotwindow<WXWINDOW> *plotwindow);
>>>>
>>>>
>>>>
>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>> //wxAppPlot
>>>>
>>>>
>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>
>>>> class wxAppPlot : public wxApp
>>>> {
>>>> public:
>>>>  virtual bool OnInit();
>>>> };
>>>>
>>>> IMPLEMENT_APP(wxAppPlot)
>>>>
>>>> bool wxAppPlot::OnInit()
>>>> {
>>>>  wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>>  frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>>>>    wxDefaultPosition,
>>>>    wxSize(900, 700));
>>>>  frame->Show();
>>>>  Plot(frame);
>>>>  return true;
>>>> }
>>>>
>>>>
>>>>
>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>> //Plot
>>>>
>>>>
>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>
>>>> template< class WXWINDOW >
>>>> void Plot(wxPLplotwindow<WXWINDOW> *plotwindow)
>>>> {
>>>>  wxPLplotstream* pls = plotwindow->GetStream();
>>>>  pls->adv(0);
>>>>  pls->scolbg(255, 255, 255);
>>>>  pls->clear();
>>>>
>>>>  //render
>>>>
>>>>  const int NSIZE = 101;
>>>>  PLFLT x[NSIZE], y[NSIZE];
>>>>  PLFLT xmin = 0, xmax = 100, ymin = 0, ymax = 10;
>>>>
>>>>  for (int i = 0; i < NSIZE; i++)
>>>>  {
>>>>    x[i] = i;
>>>>    y[i] = 5;
>>>>  }
>>>>
>>>>  plschr(0, 1.0);
>>>>  plcol0(8);
>>>>  plenv(xmin, xmax, ymin, ymax, 0, 0);
>>>>  pllab("x", "y", "Label");
>>>>  plpoin(NSIZE, x, y, 46);
>>>>
>>>>  plotwindow->RenewPlot();
>>>> }
>>>>
>>>>
>>>> -Pedro
>>>>
>>>> ----- Original Message ----- From: "Phil Rosenberg"
>>>> <p.d...@gm...>
>>>> To: "Pedro Vicente" <ped...@sp...>
>>>> Cc: <plp...@li...>;
>>>> <plp...@li...>
>>>> Sent: Thursday, October 06, 2016 5:55 AM
>>>> Subject: Re: [Plplot-devel] [Plplot-general] wxWidgets driver -- change
>>>> the
>>>> default blackbackground
>>>>
>>>>
>>>>> Hi Pedro
>>>>> The easiest way to do this at the moment is something like
>>>>>
>>>>> wxPLplotstream* pls = plotwindow->GetStream();
>>>>> pls->adv( 0 );
>>>>> pls->scolbg(255, 255, 255);
>>>>> pls->clear();
>>>>> //rest of your plotting code
>>>>>
>>>>> If you have multiple subpages then you will need to do this on each
>>>>> page. Also if your subpages don't cover all the windows then you can
>>>>> call the SetBackgroundColour method of wxPLplotwindow and this will
>>>>> clear the whole window to the given colour initially.
>>>>>
>>>>> Hope that helps. If not then let me know. I'm very open to better ways
>>>>> to do this if you have suggestions.
>>>>>
>>>>> Phil
>>>>>
>>>>>
>>>>> On 6 October 2016 at 06:00, Pedro Vicente
>>>>> <ped...@sp...> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> so, there are at least 2 solutions for this :
>>>>>> 1) the quick is just to modify the PLplot source code , in the call to
>>>>>>
>>>>>> void wxPLplotstream::Create
>>>>>>
>>>>>> comment the call to
>>>>>>
>>>>>> //init();
>>>>>>
>>>>>> then in our app code , do the init() call after Create() . as
>>>>>>
>>>>>> ~~~
>>>>>> bool wxAppPlot::OnInit()
>>>>>> {
>>>>>>   wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>>>>   frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>>>>>>     wxDefaultPosition,
>>>>>>     wxSize(900, 700));
>>>>>>   frame->Show();
>>>>>>
>>>>>>   //set background color (0) to white RGB(255,255,255)
>>>>>>   //must be called before plinit()
>>>>>>   plscolbg(255, 255, 255);
>>>>>>
>>>>>>   wxPLplotstream* pls = frame->GetStream();
>>>>>>   pls->init();
>>>>>>
>>>>>>   //change color (0) to black RGB(0, 0, 0)
>>>>>>   //must be called after plinit()
>>>>>>   plscol0(0, 0, 0, 0);
>>>>>>
>>>>>>   Plot(frame);
>>>>>>   return true;
>>>>>> }
>>>>>> ~~~
>>>>>>
>>>>>>
>>>>>> since it seems the only way to modiy the background color is to do the
>>>>>> above
>>>>>> sequence
>>>>>> this is a change that I recommend to be included in the libray, since
>>>>>> I
>>>>>> believe the other drivers require a call to init() too, but not the
>>>>>> wxWidgets driver.
>>>>>>
>>>>>> 2) not modifying the source code. In this case , I think it should be
>>>>>> possible to derive 2 classes ,
>>>>>> a) one from wxPLplotwindow
>>>>>> b) other from wxPLplotwindow
>>>>>>
>>>>>> then do everything in those classes as now except the call to init()
>>>>>>
>>>>>>
>>>>>> but if the developers could do option 1) that probably would be the
>>>>>> best
>>>>>> thanks
>>>>>>
>>>>>>
>>>>>> -Pedro
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: Pedro Vicente
>>>>>> To: plp...@li...
>>>>>> Sent: Wednesday, October 05, 2016 6:42 PM
>>>>>> Subject: [Plplot-general] wxWidgets driver -- change the default
>>>>>> blackbackground
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>>
>>>>>> I am trying to change the default black background color using the
>>>>>> wxWidgets
>>>>>> driver
>>>>>>
>>>>>> If using the SVG driver this can be done as explained here
>>>>>>
>>>>>> https://sourceforge.net/p/plplot/mailman/message/2817799/
>>>>>>
>>>>>> the trick being calling
>>>>>>
>>>>>> plscolbg()
>>>>>>
>>>>>> before
>>>>>>
>>>>>> plinit();
>>>>>>
>>>>>> like the  sample code below marked "SVG Driver" does
>>>>>>
>>>>>>
>>>>>> However for the wxWidegts driver , it seems we do not do a call to
>>>>>>
>>>>>> plinit();
>>>>>>
>>>>>> but rather this is done inside the C++ stream initialization
>>>>>>
>>>>>> From the wxWidgets PLplot sample below
>>>>>>
>>>>>> the
>>>>>>
>>>>>> plinit();
>>>>>>
>>>>>> is made inside
>>>>>>
>>>>>>
>>>>>>
>>>>>> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"));
>>>>>>
>>>>>>
>>>>>> so I don't find a way to call the plscolbg() function before
>>>>>>
>>>>>>
>>>>>> How can this be accomplished ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I also tried to modify the default colors of the default palette
>>>>>>
>>>>>> cmap0_default.pal
>>>>>>
>>>>>> 16
>>>>>> #000000
>>>>>>
>>>>>> so that the first is white
>>>>>>
>>>>>> this does work *but* only after the window is redrawn (it first shows
>>>>>> the
>>>>>> default red on black);
>>>>>> this seems like a bug to me
>>>>>>
>>>>>>
>>>>>> Also, what's the call to increase the font size?
>>>>>> On the wxWidgets driver the font looks tiny
>>>>>>
>>>>>> Thanks !
>>>>>>
>>>>>>
>>>>>> Sample code wxWidgets
>>>>>>
>>>>>>
>>>>>>
>>>>>> bool
>>>>>>
>>>>>> wxAppPlot::OnInit()
>>>>>>
>>>>>> {
>>>>>>
>>>>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>>>>
>>>>>> frame->Create(
>>>>>>
>>>>>> NULL, wxID_ANY, wxT("wxPLplot"));
>>>>>>
>>>>>> frame->Show();
>>>>>>
>>>>>> Plot(frame);
>>>>>>
>>>>>> return true;
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>>>
>>>>>> //Plot
>>>>>>
>>>>>>
>>>>>>
>>>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>>>
>>>>>> template
>>>>>>
>>>>>> < class WXWINDOW >
>>>>>>
>>>>>> void
>>>>>>
>>>>>> Plot(wxPLplotwindow<WXWINDOW> *plotwindow)
>>>>>>
>>>>>> {
>>>>>>
>>>>>> wxPLplotstream* pls = plotwindow->GetStream();
>>>>>>
>>>>>> //render
>>>>>>
>>>>>> plotwindow->RenewPlot();
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sample code SVG driver
>>>>>>
>>>>>> void
>>>>>>
>>>>>> atms_dwell_granu_t::plot()
>>>>>>
>>>>>> {
>>>>>>
>>>>>> //set SVG device and output file name
>>>>>>
>>>>>> plsdev("svg");
>>>>>>
>>>>>> plsfnam("atms_dwell_granu.svg");
>>>>>>
>>>>>> //set background color (0) to white RGB(255,255,255)
>>>>>>
>>>>>> //must be called before plinit()
>>>>>>
>>>>>> plscolbg(255, 255, 255);
>>>>>>
>>>>>> //initialize plplot
>>>>>>
>>>>>> plinit();
>>>>>>
>>>>>> //change color (0) to black RGB(0, 0, 0)
>>>>>>
>>>>>> //must be called after plinit()
>>>>>>
>>>>>> plscol0(0, 0, 0, 0);
>>>>>>
>>>>>>
>>>>>>
>>>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>>>
>>>>>> //render
>>>>>>
>>>>>>
>>>>>>
>>>>>> /////////////////////////////////////////////////////////////////////////////////////////////////////
>>>>>>
>>>>>> PLFLT xmin, xmax, ymin, ymax;
>>>>>>
>>>>>> PLFLT *x, *y;
>>>>>>
>>>>>> const int NSIZE = iOrbit_all;
>>>>>>
>>>>>> xmin = 0;
>>>>>>
>>>>>> xmax = NSIZE;
>>>>>>
>>>>>> ymin = -1.0;
>>>>>>
>>>>>> ymax = 6.0;
>>>>>>
>>>>>> x =
>>>>>>
>>>>>> new PLFLT[NSIZE];
>>>>>>
>>>>>> y =
>>>>>>
>>>>>> new PLFLT[NSIZE];
>>>>>>
>>>>>> plcol0(0);
>>>>>>
>>>>>> plenv(xmin, xmax, ymin, ymax, 0, 0);
>>>>>>
>>>>>> pllab("", "Current (Amps)", "Scan Drive Main Motor Current");
>>>>>>
>>>>>> //time axis
>>>>>>
>>>>>> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>>>>>>
>>>>>> {
>>>>>>
>>>>>> x[idx_orb] = idx_orb;
>>>>>>
>>>>>> }
>>>>>>
>>>>>> //mean
>>>>>>
>>>>>> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>>>>>>
>>>>>> {
>>>>>>
>>>>>> y[idx_orb] = DWELL_SAMPLE_APID517_Orbit[0][TLM_NUM_ORBIT -
>>>>>> 1][idx_orb];
>>>>>>
>>>>>> }
>>>>>>
>>>>>> plpoin(NSIZE, x, y, 46);
>>>>>>
>>>>>> plend();
>>>>>>
>>>>>> delete[] x;
>>>>>>
>>>>>> delete[] y;
>>>>>>
>>>>>> }
>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>> _______________________________________________
>>>>>> Plplot-general mailing list
>>>>>> Plp...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/plplot-general
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>>> _______________________________________________
>>>>>> Plplot-devel mailing list
>>>>>> Plp...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Plplot-devel mailing list
>>>> Plp...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>>
>>>
>>
>

Re: [Plplot-devel] New wxwidgets device does not honor -bg - -DOLD_WXWIDGETS=ON PL_HAVE_SNPRINTF

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

On 2016-10-09 02:27-0400 Pedro Vicente wrote:

> ok, I see the issue now.
> yes, it's possible to build each individual project in Visual Studio
>
> I just did a "build solution" , that builds all generated projects that were 
> generated by cmake
>
> the fix then is not to have cmake generate "generate_announcements" for 
> Windows,
> not only this but others too that fail
>
> Build started: Project: create_staging_announce,
> Build started: Project: check_plplotcapi_defines,
> Build started: Project: create_staging,
> Build started: Project: test_c_ps
> Build started: Project: test_c_wingcc
> Build started: Project: test_c_wxwidgets

Hi Pedro:

The problem with your suggested fix is that Windows is actually many
different platforms with a wide variety of generators.  For example,
if you used a generator that was not associated with visual studio
such as "NMake Makefiles" then there would be no capability of
indiscrimately building every target with one command so you would
never encounter the trouble you are encountering above unless you
specifically request some target that only works on platforms with
Unix capabilities.  Note also that many/all of the above targets would
work on Windows platforms with Unix capabilites such as Cygwin,
MinGW-w64/MSYS2, and MinGW/MSYS (although in those cases the
associated make command is limited in the same way as the nmake case
for Windows platforms without Unix capabilities, i.e., there is no
overall target that automatically builds every target).

So it is non-trivial to sort out which target will work on which
platform/generator and even assuming I had the time/energy to figure
that out, I would not want to complicate our build system with such
filtering for the hundreds of different targets (some of which are
quite experimental) that our build system configures.  So instead what
you should do is simply never do a "build solution" (which apparently
from your remarks above indiscriminately attempts to build every
target for visual studio).  Instead, build well-known generic targets
such as "all" (which is a misnomer because instead of building all
targets it only builds the most important subset of the targets, e.g.,
the PLplot libraries, that should build without issues on all
platforms) or "install" (which depends on "all" so all the
"all"-related targets get built) and which also installs PLplot in the
prefix location you have specified).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________