On 2014-03-04 15:23-0800 phil rosenberg wrote: > Thanks Alan, that's [referring to my good report for Debian stable] is good to hear.
> The FreeType module is working as expected. > The wxWidgets module is not perfect, but is better than not having it. It now finds wxWidgets 2.9 and 3.0. On Windows there still seem to be issues regarding finding the 64 or 32 bit version correctly - but given these issues exist in all CMake versions to date there is no harm in them being in our module. > You might be able to shed some light on them to be honest, although I get the impression Brad King is looking at them too. Basically when building a 64 bit version of Plplot using the visual studio 64 bit generator, I see lots of CMake messages saying things like detecting C compiler, then the path to the 64 bit compiler. However in the findwxWidgets module If I output the compiler path via the CMAKE_C_COMPILER variable (I might have the variable name wrong - I don't have the file in front of me) it gives the path to the 32 bit compiler. All other variables that distinguish between 32 and 64 bit seem to indicate 32 bit, except for the generator, which correctly indicates 64 bit. So somewhere along the lines something must get changed - or I'm lookign at the wrong variables. > As a fall back I have added a check for the generator name to the module in Plplot, which makes things work for the visual studio generator. When using the NMake generator the situation is worse, because there aren't separate 32 and 64 bit NMake generators, so I'm not sure of an easy workaround. There may be some environment variables that are initialised that could help, but I thought I'd wait to see if Brad comes up with anything before trying that. > If you can speculate about how the compiler can apparently change part way through the cmake call then I'll look into it further. But other than that I'm stumped. Hi Phil: My only access to Windows is via 32-bit Wine and MinGW/MSYS so I am not in a position to help because I don't have access to MSVC, the visual studio 64 bit generator or the NMake generator. I believe Arjen and Hazen are the only core developers besides yourself that has access to those. So they might be able to respond to your question. But frankly, I think you are going to need some help from the CMake developers to solve these issues since they sound like CMake bugs to me (at least at this early stage when you don't have a simple example [see below] to demonstrate the problem). My advice is those CMake developers are all incredibly busy so make it as easy for them as possible by preparing the simplest self-contained (in a tarball) example containing one simple "hello world" wxwidgets application and a simple CMake build system for that application that demonstrates the issue (say for the nmake generator). Then subscribe to the cmake development list (as opposed to the cmake list), attach that tarball to your post, and give instructions (including how to install the wxwidgets library you are using) on exactly what to do to replicate the nmake generator problem you have discovered when linking an application to the wxwidgets library. Brad King and the rest of the cmake developers hang out on that list so a simple example that is easy for them to run is likely to catch their attention. However, if your post to that list does not include such a simple example, my experience is they are probably going to ignore you. My experience is that preparing simple examples of what you think are CMake issues is worth doing in its own right. It turns out the majority of those I have implemented in the past in preparation for a post to cmake-devel never actually got posted to that list because they helped to demonstrate some misunderstanding on my part (or some bug in the PLplot build system) as opposed to some bug in CMake. Anyhow, I can certainly test your simple example (once you have implemented it) on Linux and MinGW/MSYS/Wine to make sure all is well with that example for those platforms. 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 __________________________ ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
