Hi Phil: I have also CC'd Arjen as a reminder to him to look for comments below that mention his name. :-)
On 2014-08-30 06:04-0700 phil rosenberg wrote: > Right I have now gotten to the bottom of all this > > > The include directories must contain quotes but the link libraries must not. > > Presumably the difference is because we pass include directories by first prepending -I to them and passing them in as compile flags so they are handed straight to the compiler in raw form. Whereas libraries are passed as filenames to CMake and are processed before being passed to the compiler. Exactly. > The only ambiguity left is that I don't know what the situation should be for the RPATH variables as I don't really know what they do or how they are used. Alan can you advise? See http://stackoverflow.com/questions/107888/is-there-a-windows-msvc-equivalent-to-the-rpath-linker-flag for some background. My understanding is CMake just ignores RPATH settings on all Windows platforms. So you don't have to be concerned with RPATH at all. However, just in case your changes dealing with blanks have had a side-effect on RPATH that might affect other platforms, don't worry about that. If my test of your push (which I presume you will be making soon) on Linux shows you have introduced some RPATH issues on that platform, I will deal with those. It appears below, you now have gotten everything to work (subject possibly to a transitive linking issue for CMake-3 that you have worked around by hand) for the -G"Visual Studio 11 Win64" -DBUILD_SHARED_LIBS=OFF -DSTATIC_RUNTIME=ON case. IMPORTANT. So please go ahead and commit and push your build-system changes so I can test them here. And kudos to you for obviously learning a lot about the CMake language while pioneering the above case with Tcl/Tk installed in a prefix area that contains blanks in the name. The CMake knowledge you have developed during this effort will help you a lot down the road not only with PLplot but likely other free software projects as well. After you make that push, please go ahead and also pioneer your platform (this time with CMake-2.8.12.2, see below) without the -DBUILD_SHARED_LIBS=OFF -DSTATIC_RUNTIME=ON cmake options. That is the (default) case that most Windows users will be using so it would be valuable to make sure it works for your Tcl/Tk case. Further response below to some of the points you made in the forwarded section of your e-mail. > Okay so here goes, please bear with me with all this. > 1) I am already using CMAKE 3.0. I presume this is from when I had wxWidgets > problams and was discussing things with Brad. I would still recommend you go back to using CMake-2.8.12.2. The problem is that CMake-3.0 is complaining about that part of our build-system that enforces transitive linking for the Windows case. And the further remarks you make about that below indicate that CMake-3-only issue may be affecting you. If you do need something from CMake-3.0 such as a more modern wxwidgets find module it is easy to try that (by copying the relevant file to cmake/modules in the PLplot source tree). And if that latest version of the find module works for you with CMake-2.8.12.2 then commit and push it to our repo so all our users still using CMake-2.8.x will benefit. > 2) I tried using the nmake generator. It failed. It tried to build a test program to test the compiler, which failed - cl.exe reported "could not find kernel32.lib." Therefore as CMAKE was unable to find a working c compiler it exited. This is obviously ridiculous as I clearly have a working c compiler. Can't help you there, but I bet Arjen can since he routinely uses the nmake generator without such issues. > 3) I unfortunately don't have time to start fighting with the NMake generator so I am returning back to the visual studio generator. Fair enough. I should tone down the negative things I said about the visual studio generators since you obviously got one of them to work. But I will say this: there are lots of such visual studio generators and at least one new one each year so CMake development resources to flush out the bugs are spread thin. In comparison nmake has been around forever so that generator is completely mature. Also, in your case the VS generator worked, but that may be because it is relatively mature, and when you update your VS version you will also have to update to a newer VS generator to be consistent with it. So in that case you might run into issues for a while until the genrator matures. Therefore, in my view it is always worthwhile to have the nmake generator available so I hope Arjen responds above to get you squared away with nmake to use as a reliable fallback when needed. > 4) The missing piece of information that led to me getting the cMAKE sequence correct was that when calling target_link_libraries and adding a library that you are building, all libraries added to that library are added as well. Note however that (at least for the VS generator) if I add libraries to a library they don't actually get added!!! Confused? Well so have I been. Basically we add all the dependancies to the plplot library. CMake remembers we have added them, I follow your summary thus far. However, you have to clearly distinguish what we tell CMake to do via our CMake build system logic compared with the actual build result that is generated by CMake (and which you access using the VERBOSE=1 option in the nmake case, but I don't know what is required in the VS case). For example, it is often the case that an app links to a library which links to other libraries the app is completely unaware of. (For example, our C examples link to the plplot core library but are completely unaware that that library has other library dependencies since the app uses nothing directly from those other libraries.) For this case in CMake you only express direct library dependencies in the target_link_libraries statement and ignore the indirectly linked ones. Then CMake (including the particular generator logic you are using) is supposed to translate that information into something that is correct for the platform, i.e., some platforms like Linux are completely happy with mentioning only directly linked libraries (so-called non-transitive linking) to the linker while others demand all directly and indirectly linked libraries are mentioned, i.e., so-called transitive linking. Another complication is that CMake does have issues with how non-transitive linking works on Windows so we force transitive linking in that case, and that works very well for CMake-2.8.x. (See the NON_TRANSITIVE option which is set to OFF for Windows in cmake/modules/plplot.cmake, and which is used, e.g., in src/CMakeLists.txt to force transitive linking for Windows). However, it is exactly this transitive logic in src/CMakeLists.txt and elsewhere that CMake-3 is issuing warnings about. So for CMake-3 there may be an issue such that non-transitive linking is (incorrectly) being used for Windows (see below). > but when it creates the plplot project it doesn't actually add them as additional dependancies. The VS generator should know the VS platform requirements about whether linking should be non-transitive or transitive. So if you have to enforce transitive linking by hand (by entering all those dependencies by hand), then I believe that is due to a CMake-3 inconsistency with our build-system logic (see comment above) or else possibly a VS generator bug. Of course, eventually I should be able to adjust our build system logic for the new CMake methods that are available for specifying non-transitive and transitive linking in CMake-3.0. But for now, I suggest you avoid CMake-3.0 and stick with CMake-2.8.12.2. > 4) The output of the CMAKE command is as follows, note that I uncommented the lines to output libplplot_LINK_LIBRARIES, just before the target_link_libraries call. For equivalent cases in the future, it would be much more convenient for me if you included such information in a compressed attachment (which does not subject it to mail wraparound problems). However, I did look at it this time, and the libplplot_LINK_LIBRARIES result looks OK to me. I also like > -- Start determining consistent system data for Tcl and friends [...] > -- Finished determining consistent system data for Tcl and > friends with harmless warnings in there about missing itcl and itk on your system. I also judge the other warnings you encountered to be harmless except for the CMake-3 warnings about 2.8.x code that enforces transitive linking in the Windows case and which is apparently causing some problems for you. > 7)Frustratingly these build problems just keep on coming up in Windows - Windows is rather more ad-hoc with building from source than Linux. Often libraries are not where one might expect and people regularly use static libraries and static runtimes. Then there is the Unicode issue. On Linux the runtime is included with the distro so in general everyone uses dynamic runtime and as Linux has a package manager things are almost always where you expect and it is generally relatively easy to add a dependant library if it is missing and deal with dll hell. I'm not sure what the suitable answer is - I'm not sure if there is any way to become less dependant upon Cmake or even if that would be a good thing. It's just a shame CMake isn't at a stage yet where it "just works" on Windows. I agree that free software binary distribution of individual packages of Windows is currently in a mess with a "wild-west" philosophy where there is no consistency between individual binary packages about where everything is installed, not consistent ABI, etc. (In fact, this is the fundamental reason we have never bothered with binary distribution of PLplot on Windows.) So given this situation, CMake Windows users for now have to be aware of all the tools at their disposal (such as the CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH environment variables) to provide help to CMake to find all required external libraries in various odd install locations and just cross their fingers on potential ABI inconsistency issues (unless they build everything themself with something like cmake/epa_build). Another Windows issue that CMake has faced pretty well (using, e.g., a very large and increasing number of VS generators) is there are a very large set of Windows platforms with different build rules between them. In contrast, it is obviously much easier for CMake to operate on Unix platforms where the "Unix Makefiles" generator is used in the vast majority of cases. In the long term, the solution is for a volunteer or group of such volunteers to create a free software distribution for Windows that enforces a self-consistent set of packaging rules for each free software package that is included in that particular distro. Cygwin is already one such effort (in this case backed by RedHat rather than volunteers), and MinGW-w64/MSYS2 is another such distribution that has been put together quite recently by volunteers and is rapidly gaining mindshare. So if this and similar volunteer efforts continue to expand, the known current issues with binary distribution of individual packages on Windows should eventually no longer be of concern. 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 __________________________ ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
