From: Alan W. I. <ir...@be...> - 2017-06-23 11:51:26
|
On 2017-06-23 11:12-0000 Arjen Markus wrote: > Hi Alan, > > > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@be...] >> Sent: Friday, June 23, 2017 1:04 PM >> >> Hi Arjen: >> >> Thanks very much for that quick turnaround. >> > You're welcome :) > >>> I get compile errors as can be seen in the attached tarball (output >> from CMake and make, as well as the config header file). We need to sort out these >> things before a comprehensive build is going to stand any chance. >> >> From what I can tell from your current extremely limited make.out (please generate >> that next time with VERBOSE=1), it looks like these build issues have nothing to do >> with PLplot code and instead are wxwidgets header incompatibilities _for the >> compile flags that are being generated by your current Unix wxwidgets find >> method_. >> >> Therefore, I am pretty sure the current build issue is caused by your build using >> Unix wxwidgets compile and link flags when it should be using Windows wxwidgets >> compile and link flags for the MinGW-w64/MSYS2 platform. So to get access to the >> latter flags, I suggest you use the _Windows_ wxwidgets find method (which I >> understand you automatically obtain if you use the "MSYS Makefiles" generator.) >> > > I do not think so, the condition definitely says "AND NOT MSYS" - so that would use the Unix method. You are right. So without your one-line change to FindwxWidgets.cmake, the "Unix Makefiles" generator or "MinGW Makefiles" generator will yield set(wxWidgets_FIND_STYLE "win32") while (confusing) the "MSYS Makefiles" generator will yield set(wxWidgets_FIND_STYLE "unix") > >> If I have understood correctly what you said before, the Windows wxwidgets find >> method currently does not work for the MinGW-w64/MSYS2 platform. Nevertheless, >> since our wxwidgets code with old IPC method did build correctly on MSVC before >> with this find method, I assume whatever correction you have to make to >> cmake/modules/findwxWidgets.cmake to get the Windows find method to work >> correctly on the MinGW-w64/MSYS2 platform should be quite small. >> And as per usual, the cmake options --debug-output --trace are extremely useful for >> debugging find modules, but if those are not sufficient to discover the problem, you >> can always locally insert >> message(...) commands in cmake/modules/findwxWidgets.cmake. >> > > Ah, but the issue is that under MinGW-w64/MSYS2 things are installed in different directories and possibly a different structure than under Windows with MSVC. MinGW-w64/MSYS2 is a bit of a hybrid system, though leaning towards the Unix way. I agree on the hybrid nature of that platform and very likely part of that is the wxwidgets libraries are built on MinGW-w64/MSYS2 the "Windows" way since X is (thankfully since it is so slow on Windows) not available on that platform. Anyhow, I would advise dumping out compile (and link) flag results for both the set(wxWidgets_FIND_STYLE "win32") and set(wxWidgets_FIND_STYLE "unix") cases to see what the differences are (which I think were originally designed for the "MinGW Makefiles" and "MSYS Makefiles" cases for the old MinGW/MSYS platform). Because of the hybrid nature of MinGW-w64/MSYS2 you might need some combination of both sets of those compile flags (e.g., -I flags from "unix" results and the other non-I compile flags from "win32" results. Or vice versa). 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 __________________________ |