On 2016-11-14 23:39-0500 Pedro Vicente wrote: > all is fine > > so, the problem was that I was using git bash for Windows as shell (where > back-slash forward-slash convention is different from Unix/Windows; as a > software engineer I end up losing hours of my life fixing > different Unix/Windows path conventions. Thanks Microsoft). > > Using just a "normal" Windows shell , this works > > -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib > > in > > 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 > > > sorry for all the false alarms
Hi Pedro: No problem. Been there done that (when I was playing with MinGW/MSYS under Wine years ago.) In sum, I am glad you no longer encounter wxwidgets find issues. > > Just 2 last notes :-) > > > 1) > > If we specify the root of wxWidgets with > > -DwxWidgets_ROOT_DIR:PATH=%WXWIN% > > it seems that having to specify the library path could be eliminated > > -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib > > I believe this path > > \lib\vc_lib > > is always the same for any Windows build? If not than my point is not valid I believe you are correct. So try it and see. > > 2) > > After building with Visual Studio, all built ok > > ========== Rebuild All: 88 succeeded, 0 failed, 0 skipped ========== > > but in the last release there was an automatic run of the plot demo, that > shows a plot window, that did not show up this time > > no big deal, but it's a nice feature that shows that all went fine If you are concerned about a test that is suddenly missing from (say) the test_interactive target, then you should look for WARNING messages in the cmake output concerning test targets. Those warnings typically end with a phrase similar to "... so it is temporarily excluded from being a dependency of other more general interactive test targets" We typically use such warnings for issues we can do nothing about except wait for external libraries to fix bugs. So typically you can run such targets as an individual test, but you will encounter segfaults that would ruin more comprehensive testing so we exclude these problematic test targets from being part of more comprehensive testing in the interest of allowing the comprehensive tests to finish under normal circumstances. For example, today I found two other such problematic tests under Qt5 (test_qt_example and test_pyqt5_example). I ascribe these to Qt5 immaturity so the only thing we can do about these is wait for the bugs in Qt5 memory management to be fixed. So those two tests are shortly going to be excluded from the test_interactive target (with a CMake WARNING similar to the above message to remind us to test the individual targets from time to time to see if the external library at fault has fixed its problems). 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
