On 2017-05-19 07:53+0200 Thomas Gläßle wrote: > > Alan W. Irwin wrote on 05/19/2017 03:11 AM: >> Yet from your report no such "auto"-related targets seem to be >> available for >> the CMake version on MinGW-w64/MSYS2. >> >> Just to confirm that conclusion, what are your results for >> >> make help |grep -i auto >> >> executed in the top directory of your build tree? > > Empty results. > > When grepping the whole directory there are matches, some of them > autogen related. See attached `grep_auto.out` file.
Hi Thomas: Thanks for this report. Figuring this out is going to be fairly time consuming so I don't ask that of you and instead the following notes are for a PLplot developer with access to MinGW-w64/MSYS2 that might want to take on this issue. @Developers: I had an extremely quick look at the grep_auto.out results, and it does appear the Makefiles generated by CMake do have many of the correct rules in place for moc to generate the required source code. So the CMake bug appears to be that some key component of those rules is missing on this platform, but figuring out exactly what is wrong (say by doing detailed comparisons between the equivalent Linux and MinGW-w64/MSYS2 results) is going to take a lot of work. To simplify that work, you should do such a comparison only for the simplest possible test project example. Right now we do have a fairly simple test project implemented at cmake/test_automoc/CMakeLists.txt, but that project was implemented to compare various ways of using moc with CMake so it needs to be simplified even more ( i.e., to reduce it to just one example of automoc at work following the style that I finally adopted in bindings/qt_gui/CMakeLists.txt). > I had a few bugs with gcc and other tools on this platform, so this > could be a possibility.. > On the other hand I could (and still can) successfully build plplot > 5.9.9 - meaning that I can successfully make this version of plplot and > also link another program with the generated libraries. (Sorry, I > realize I should have pointed this out earlier.. but somehow I forgot). @Thomas: Yes, using the CMake automoc capability (that apparently is failing for you on the MinGW-w64/MSYS2 platform but which works fine on the Linux platform) was implemented first for 5.12.0. Before that we used a brute force technique to generate the moc files which had problems of its own that were solved by using the CMake capability. So I would far prefer to continue to use the CMake capability but find out what is wrong with it just for MinGW-w64/MSYS2. > I'm already on cmake 3.8.1 in the msys. Yes, but presumably that is a patched version, and it would be interesting to see if an unpatched version (that you built yourself) did not have this issue. In other words, such an experiment would be part of finding out what is the source of this issue which (1) could be some problem with the patches applied by the MinGW-w64/MSYS2 packagers or (2) could be some problem with unpatched CMake automoc capability on this platform that the CMake developers did not anticipate. I got your later e-mail that it would be a while before you could try this experiment, but that is fine since our own developer will likely be trying this experiment instead. Anyhow, you sure found an "interesting" problem.... :-) > >> Another >> possibility is to try Qt5 instead. You do that by (1) installing the >> Qt5 development libraries and (2) convince our build system (which >> prefers Qt4 by default) to use those libraries by using the >> -DPLPLOT_USE_QT5=ON cmake option. > > I will have to check up on that. However, I will be away for one week > with no access to my windows desktop - so expect nothing in the next few > days. (I have the whole build tree with me if you need more info). I think that is an extreme long shot that the Qt development packages might be at fault rather than CMake itself so let us just forget that possibility for now. > >> A final possibility is to give up on >> our qt devices altogether on this platform (at least for now) by >> disabling all of them (using the cmake option >> -DDEFAULT_NO_QT_DEVICES=ON). > > Which devices can you suggest instead? I used Qt because it was the > first one I got working on the older plplot. Given the automoc trouble with qt on this platform, I would recommend the cairo device driver which implements both noninteractive and interactive devices that typically are of the same high quality as the equivalent qt devices. One issue is there will be a lot to install starting with pkg-config. But keep following up any WARNINGs in cmake.out corresponding to "cairo" or "pango" in cmake.out by installing the relevant MinGW-64/MSYS2 packages and you should be OK. Note that cairo and pango are a subset of GTK+, so see the name of the relevant GTK+ package you should install in <https://sourceforge.net/p/plplot/wiki/MinGW-w64-MSYS2/>. Furthermore, if you spot any issues with that list of package names, please let me know so we can fix it. An additional potential "cairo" issue on this platform is the interactive xcairo device will not work because there is no X on this platform. We have implemented an interactive device called wincairo which is a replacement for xcairo that is designed to work on Windows. So ideally that device will provide you interactive capability. However, I should warn you that device is not well tested yet so we would all be most interested in how well it works for you. > Installed a few of packages and silenced many of the WARNINGs, however > still the same error occurs. As expected since the two issues are unlikely to be related. 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-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
