Hi Alan
Unfortunately (or fortunately, depending upon your viewpoint) a simple test
case that I ran for Brad showed that CMake was reporting the 64 bit compiler
correctly, so indicates something deeper in the Plplot build system is
happening. Unfortunately it is beyond my skills with CMake to find it, although
I have looked. It almost seems like sometime before the findwxWidgets module is
called the variables relating to the compiler all get changed or reset somehow.
I have however added a workaround to the module so that as well as checking the
CMAKE_CL_64 variable it also checks the generator name and an environment
variable which must be set to use the NMake generator. On my system I now get
the correct wxWidgets "bitness" for both visual studio and nmake build systems.
Phil
On Wednesday, 5 March 2014, 0:48, Alan W. Irwin <[email protected]>
wrote:
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
