PLplot

Hi Hazen,

On Jul 15, 2009, at 7:14 PM, Hazen Babcock wrote:

>
> (1) Do we have a minimum c++ version requirement? I couldn't find
> anything in the archives but when I tried to run cmake on svn head I  
> get
> this error:
>
> CMake version = 2.6.4
> The CXX compiler identification is GNU
> CMake Error at cmake/modules/c++.cmake:57 (message):
>   C++ compiler absolutely required to build this project.
> Call Stack (most recent call first):
>   cmake/modules/plplot.cmake:127 (include)
>   CMakeLists.txt:82 (include)
>
> I also tried with 5.9.4 and I did not see this problem. I have the
> standard mingw c++ version 3.4.5, which is perhaps a little dated?

3.4.5 is fine, it was until recently the standard MinGW version - just  
recently they released 4.4.4 (big step), but I don't think anybody  
tested plplot with that version so it's best to stick with 3.4.5 which  
is well tested. Did you install the the g++ compiler package? Did you  
choose the correct generator for cmake? If you have MinGW without MSYS  
you need to use the generator "MinGW Makefiles", if you compile inside  
MSYS you need "MSYS Makefiles". The latter I think is chosen  
automatically, but the MinGW Makefiles I believe not. How do you  
invoke cmake and in MSYS or in cmd.exe?
>
> (2) When I try to run a python example I get "ImportError: No module
> named _plplotc". I have python2.6, numpy 1.3.0 and swig(swigwin?)
> 1.3.39. Is there anything special that I need to do to use Python/ 
> PLplot
> on windows?

I once tested Python 2.4 on Windows and it kinda worked. Wait - I  
wrote a message that days and you can read it here:

http://www.mail-archive.com/plplot-devel@...>

maybe this thread is of any help for you, keep us posted.

Regards,
Werner
>
> thanks,
> -Hazen
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited  
> time,
> vendors submitting new applications to BlackBerry App World(TM) will  
> have
> the opportunity to enter the BlackBerry Developer Challenge. See  
> full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel


--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: smekal@...
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
        +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

On Wed, Jul 15, 2009 at 01:14:59PM -0400, Hazen Babcock wrote:
> 
> (1) Do we have a minimum c++ version requirement? I couldn't find 
> anything in the archives but when I tried to run cmake on svn head I get 
> this error:
> 
> CMake version = 2.6.4
> The CXX compiler identification is GNU
> CMake Error at cmake/modules/c++.cmake:57 (message):
>    C++ compiler absolutely required to build this project.
> Call Stack (most recent call first):
>    cmake/modules/plplot.cmake:127 (include)
>    CMakeLists.txt:82 (include)
> 
> I also tried with 5.9.4 and I did not see this problem. I have the 
> standard mingw c++ version 3.4.5, which is perhaps a little dated?

To follow on from Werner's response: You shouldn't _need_ a C++ compiler
to compile plplot. All the core code is C. Of course you won't get the
C++ bindings or the drivers which are written in C++. Having said this
it looks like the cmake system currently insists you have one.

Andrew

Werner Smekal wrote:
> Hi Hazen,
> 
> On Jul 15, 2009, at 7:14 PM, Hazen Babcock wrote:
> 
>> (1) Do we have a minimum c++ version requirement? I couldn't find
>> anything in the archives but when I tried to run cmake on svn head I  
>> get
>> this error:
>>
>> CMake version = 2.6.4
>> The CXX compiler identification is GNU
>> CMake Error at cmake/modules/c++.cmake:57 (message):
>>   C++ compiler absolutely required to build this project.
>> Call Stack (most recent call first):
>>   cmake/modules/plplot.cmake:127 (include)
>>   CMakeLists.txt:82 (include)
>>
>> I also tried with 5.9.4 and I did not see this problem. I have the
>> standard mingw c++ version 3.4.5, which is perhaps a little dated?
> 
> 3.4.5 is fine, it was until recently the standard MinGW version - just  
> recently they released 4.4.4 (big step), but I don't think anybody  
> tested plplot with that version so it's best to stick with 3.4.5 which  
> is well tested. Did you install the the g++ compiler package? Did you  
> choose the correct generator for cmake? If you have MinGW without MSYS  
> you need to use the generator "MinGW Makefiles", if you compile inside  
> MSYS you need "MSYS Makefiles". The latter I think is chosen  
> automatically, but the MinGW Makefiles I believe not. How do you  
> invoke cmake and in MSYS or in cmd.exe?

In my first attempts I followed the instructions on the wiki, i.e.:
c:\path\to\cmake \path\to\source -G "MinGW Makefiles"

However this failed here:
-- Looking for gdi32 header and library
-- Looking for gdi32 header and library - found

At which point a dialog box pops up:
Title: "Windows - No Disk"
Message: "Exception Processing Message XX Parameters YY YY YY"
Buttons: "Cancel, Try Again, Continue"

So I was using the cmake GUI instead, which works nicely for plplot5.9.4 
but for some reason gives the c++ error with plplot-svn-head.

Going back to the command line cmake I don't see the C++ problem with 
plplot-svn-head but I am again hung up on whatever the gdi32 problem is.

>> (2) When I try to run a python example I get "ImportError: No module
>> named _plplotc". I have python2.6, numpy 1.3.0 and swig(swigwin?)
>> 1.3.39. Is there anything special that I need to do to use Python/ 
>> PLplot
>> on windows?
> 
> I once tested Python 2.4 on Windows and it kinda worked. Wait - I  
> wrote a message that days and you can read it here:
> 
> http://www.mail-archive.com/plplot-devel@...>
> 
> maybe this thread is of any help for you, keep us posted.

Thanks. It looks helpful. I assume that the copying step is still necessary?

-Hazen

On 2009-07-15 19:29+0100 Andrew Ross wrote:

> On Wed, Jul 15, 2009 at 01:14:59PM -0400, Hazen Babcock wrote:
>>
>> (1) Do we have a minimum c++ version requirement? I couldn't find
>> anything in the archives but when I tried to run cmake on svn head I get
>> this error:
>>
>> CMake version = 2.6.4
>> The CXX compiler identification is GNU
>> CMake Error at cmake/modules/c++.cmake:57 (message):
>>    C++ compiler absolutely required to build this project.
>> Call Stack (most recent call first):
>>    cmake/modules/plplot.cmake:127 (include)
>>    CMakeLists.txt:82 (include)
>>
>> I also tried with 5.9.4 and I did not see this problem. I have the
>> standard mingw c++ version 3.4.5, which is perhaps a little dated?
>
> To follow on from Werner's response: You shouldn't _need_ a C++ compiler
> to compile plplot. All the core code is C. Of course you won't get the
> C++ bindings or the drivers which are written in C++. Having said this
> it looks like the cmake system currently insists you have one.

Actually, we _were_ dependent on having a C++ compiler because the psttf
device and octave bindings failed horribly without one, and
check_prototype_exists (unnecessarily) demanded a working C++ compiler.  I
have just now (revision 10150) fixed all those issues so that for the first
time a working C++ compiler is optional, i.e., the -DENABLE_cxx=OFF option
works for the first time (i.e., by automatically turning PLD_psttf and
ENABLE_octave to OFF), and if you don't use that option, but a C++ compiler
cannot be found, the build system recovers gracefully by forcing
ENABLE_cxx=OFF.  (I just checked that graceful recovery by temporarily
renaming /usr/bin/g++.)

Revision 10150 should clear up some obfuscating issues, but I suspect
Hazen's underlying issue (cannot find a C++ compiler) will still generate a
warning (and ENABLE_cxx=OFF).  Hazen, will you confirm your problem now
shows up as that warning for svn trunk?

Furthermore, if you are still getting a warning (now) about a missing C++
compiler, I frankly don't understand why 5.9.4 works for you at all without
erroring out at cmake time. The C++ language was an absolute requirement for
5.9.4.  The method used to find C++ had a different top-level (the project
command without any languages specified is the same as demanding C and C++),
but the underlying method (CMakeDetermineCXXCompiler) for finding the C++
compiler should be identical. Are you using the exact same generator and
environment variables for both PLplot 5.9.4 and PLplot svn trunk? The
generator and CXX environment variable will make a difference to whether you
find a C++ compiler or not.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Alan W. Irwin wrote:
> On 2009-07-15 19:29+0100 Andrew Ross wrote:
> 
>> On Wed, Jul 15, 2009 at 01:14:59PM -0400, Hazen Babcock wrote:
>>> (1) Do we have a minimum c++ version requirement? I couldn't find
>>> anything in the archives but when I tried to run cmake on svn head I get
>>> this error:
>>>
>>> CMake version = 2.6.4
>>> The CXX compiler identification is GNU
>>> CMake Error at cmake/modules/c++.cmake:57 (message):
>>>    C++ compiler absolutely required to build this project.
>>> Call Stack (most recent call first):
>>>    cmake/modules/plplot.cmake:127 (include)
>>>    CMakeLists.txt:82 (include)
>>>
>>> I also tried with 5.9.4 and I did not see this problem. I have the
>>> standard mingw c++ version 3.4.5, which is perhaps a little dated?
>> To follow on from Werner's response: You shouldn't _need_ a C++ compiler
>> to compile plplot. All the core code is C. Of course you won't get the
>> C++ bindings or the drivers which are written in C++. Having said this
>> it looks like the cmake system currently insists you have one.
> 
> Actually, we _were_ dependent on having a C++ compiler because the psttf
> device and octave bindings failed horribly without one, and
> check_prototype_exists (unnecessarily) demanded a working C++ compiler.  I
> have just now (revision 10150) fixed all those issues so that for the first
> time a working C++ compiler is optional, i.e., the -DENABLE_cxx=OFF option
> works for the first time (i.e., by automatically turning PLD_psttf and
> ENABLE_octave to OFF), and if you don't use that option, but a C++ compiler
> cannot be found, the build system recovers gracefully by forcing
> ENABLE_cxx=OFF.  (I just checked that graceful recovery by temporarily
> renaming /usr/bin/g++.)
> 
> Revision 10150 should clear up some obfuscating issues, but I suspect
> Hazen's underlying issue (cannot find a C++ compiler) will still generate a
> warning (and ENABLE_cxx=OFF).  Hazen, will you confirm your problem now
> shows up as that warning for svn trunk?

This works.

> Furthermore, if you are still getting a warning (now) about a missing C++
> compiler, I frankly don't understand why 5.9.4 works for you at all without
> erroring out at cmake time. The C++ language was an absolute requirement for
> 5.9.4.  The method used to find C++ had a different top-level (the project
> command without any languages specified is the same as demanding C and C++),
> but the underlying method (CMakeDetermineCXXCompiler) for finding the C++
> compiler should be identical. Are you using the exact same generator and
> environment variables for both PLplot 5.9.4 and PLplot svn trunk? The
> generator and CXX environment variable will make a difference to whether you
> find a C++ compiler or not.

I believe everything is the same. I am using the CMake GUI configuration 
utility and not the command line cmake (due to the apparent gdi32 
issue). The problem is that cmake-gui-plplot-5.9.4 considers my C++ 
compiler to be findable/acceptable whereas cmake-gui-plplot-svn does 
not. Note that cmake-gui-plplot-svn does find a Gnu CXX compiler but 
then errors out anyway. Any ideas about what might have changed to lead 
to this difference would be appreciated. I'd like to get Qt and PyQt 
working on the windows computer that I have access to so I'll need to 
get past this C++ hang up (and/or figure out the gdi32 thing so that I 
can use the command line version of cmake).

-Hazen

On 2009-07-15 17:53-0400 Hazen Babcock wrote:

> Alan W. Irwin wrote:
>> [...]Furthermore, if you are still getting a warning (now) about a missing C++
>> compiler, I frankly don't understand why 5.9.4 works for you at all without
>> erroring out at cmake time. The C++ language was an absolute requirement 
>> for
>> 5.9.4.  The method used to find C++ had a different top-level (the project
>> command without any languages specified is the same as demanding C and 
>> C++),
>> but the underlying method (CMakeDetermineCXXCompiler) for finding the C++
>> compiler should be identical. Are you using the exact same generator and
>> environment variables for both PLplot 5.9.4 and PLplot svn trunk? The
>> generator and CXX environment variable will make a difference to whether 
>> you
>> find a C++ compiler or not.
>
> I believe everything is the same. I am using the CMake GUI configuration 
> utility and not the command line cmake (due to the apparent gdi32 issue). The 
> problem is that cmake-gui-plplot-5.9.4 considers my C++ compiler to be 
> findable/acceptable whereas cmake-gui-plplot-svn does not. Note that 
> cmake-gui-plplot-svn does find a Gnu CXX compiler but then errors out anyway. 
> Any ideas about what might have changed to lead to this difference would be 
> appreciated. I'd like to get Qt and PyQt working on the windows computer that 
> I have access to so I'll need to get past this C++ hang up (and/or figure out 
> the gdi32 thing so that I can use the command line version of cmake).

Try disabling the wingcc device to avoid anything to do with gdi32.  Does that
solve all your Windows build issues?

If under those conditions cmake works, but the cmake GUI does not for the
svn trunk version, then that probably means my recent changes in how C++ is
found have exposed a bug in cmake-gui.  Frankly, I far prefer the cmake
application since it makes it much easier to replicate issues.  With a GUI
it is never clear exactly what buttons got pushed in what order to generate
the bug, certain sequences of commands can generate stale cache issues, and
output is often difficult to capture.  Furthermore, the cmake application is
a mature product while I believe cmake-gui was only introduced at the start
of the cmake-2.6.x series so there are likely to be more bugs in it than the
cmake application.

That said, I will try to replicate the issue with the cmake-gui application
on Linux.  By default cmake-gui is not built on Linux, but I just discovered
that it does get built and installed if you use the CMake bootstrap --qt-gui
option and qmake (from your qt development environment) is on your path.

More later.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On 2009-07-15 16:19-0700 Alan W. Irwin wrote:

> If under those conditions cmake works, but the cmake GUI does not for the
> svn trunk version, then that probably means my recent changes in how C++ is
> found have exposed a bug in cmake-gui.

I confirm this cmake-gui issue on Linux with the PLplot build and also for the
following really simple test case.

#stanza 1
project(test NONE)
cmake_minimum_required(VERSION 2.6.4)

#stanza 2
include(CMakeDetermineCXXCompiler)
message(STATUS "CMAKE_CXX_COMPILER = ${CMAKE_CXX_COMPILER}")

#stanza 3
enable_language(CXX OPTIONAL)
message(STATUS "CMAKE_CXX_COMPILER_WORKS = ${CMAKE_CXX_COMPILER_WORKS}")

The above combination is essential for the soft-landing logic, but it turns
out that combination exposes a cmake-gui bug
(CMAKE_<language>_COMPILER_WORKS is undefined for that combination) which I
have reported to the CMake list.  For those following that list, I thought
of a particular workaround for the cmake-gui bug, but it turns out that
solution does not work for PLplot because cmake-gui leaves additional
essential language variables undefined for combinations like the above.

So we have the ugly choice of hard landings if any (!) of Ada, C++, D,
Fortran, or Java developments are missing (the model used in PLplot release
5.9.4 and rightly objected to by Geoffrey since it gives a bad first
impression) or use the present soft-landing system which precludes using
cmake-gui since that application currently gets confused (essential language
variables become undefined for some reason) by combinations like the above
stanza 2 and 3 for any language.  To summarize the choice we can have
no soft landings or no cmake-gui.

Which is the preferred choice that we use until this can of worms is cleaned
up by the CMake developers?

I would be happy to implement whatever we decide and write up the resulting
limitation in our build system (no soft landings or no cmake-gui) in
README.release.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On 2009-07-15 22:46-0700 Alan W. Irwin wrote:

> [...]To summarize the choice we can have
> no soft landings or no cmake-gui.
>
> Which is the preferred choice that we use until this can of worms is cleaned
> up by the CMake developers?
>
> I would be happy to implement whatever we decide and write up the resulting
> limitation in our build system (no soft landings or no cmake-gui) in
> README.release.

Ugh.  I just had pointed out to me by a CMake user on the CMake list (and I
also confirmed) that ccmake also has the same problem as cmake-gui.  So if
the CMake developers can't come up with a workaround for this ccmake AND
cmake-gui issue I will probably go back to the 5.9.4 hard landing model.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Alan W. Irwin wrote:
> On 2009-07-15 17:53-0400 Hazen Babcock wrote:
> 
>> Alan W. Irwin wrote:
>>> [...]Furthermore, if you are still getting a warning (now) about a missing C++
>>> compiler, I frankly don't understand why 5.9.4 works for you at all without
>>> erroring out at cmake time. The C++ language was an absolute requirement 
>>> for
>>> 5.9.4.  The method used to find C++ had a different top-level (the project
>>> command without any languages specified is the same as demanding C and 
>>> C++),
>>> but the underlying method (CMakeDetermineCXXCompiler) for finding the C++
>>> compiler should be identical. Are you using the exact same generator and
>>> environment variables for both PLplot 5.9.4 and PLplot svn trunk? The
>>> generator and CXX environment variable will make a difference to whether 
>>> you
>>> find a C++ compiler or not.
>> I believe everything is the same. I am using the CMake GUI configuration 
>> utility and not the command line cmake (due to the apparent gdi32 issue). The 
>> problem is that cmake-gui-plplot-5.9.4 considers my C++ compiler to be 
>> findable/acceptable whereas cmake-gui-plplot-svn does not. Note that 
>> cmake-gui-plplot-svn does find a Gnu CXX compiler but then errors out anyway. 
>> Any ideas about what might have changed to lead to this difference would be 
>> appreciated. I'd like to get Qt and PyQt working on the windows computer that 
>> I have access to so I'll need to get past this C++ hang up (and/or figure out 
>> the gdi32 thing so that I can use the command line version of cmake).
> 
> Try disabling the wingcc device to avoid anything to do with gdi32.  Does that
> solve all your Windows build issues?

It looks like the problem is actually somewhere in the PLD_wxwidgets 
logic. If I set PLD_wxwidgets=OFF then everything else seems to work 
(for both plplot-svn and plplot-5.9.4).

-Hazen

> On 2009-07-15 22:46-0700 Alan W. Irwin wrote:
>
>> [...]To summarize the choice we can have
>> no soft landings or no cmake-gui.

I have just committed (revision 10153) the hard-landing solution because
there is no way I wanted to have both ccmake and cmake-gui provide broken
language results such as found by Hazen and confirmed in detail by me.

However, immediately after I did that commit, the CMake gurus on the CMake
list came up with a temporary workaround for bug
http://public.kitware.com/Bug/view.php?id=9220.  The workaround should
provide a soft landing for both the missing and broken compiler cases which
I think will work quite well.  However, the implementation of this idea (to
run a simple cmake configuration from within cmake to check on each compiler
in question) is non-trivial so it will take me a while to finish with this
issue.

So more later.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Hazen Babcock wrote:
> Alan W. Irwin wrote:
>> On 2009-07-15 17:53-0400 Hazen Babcock wrote:
>>
>>> Alan W. Irwin wrote:
>>>> [...]Furthermore, if you are still getting a warning (now) about a missing C++
>>>> compiler, I frankly don't understand why 5.9.4 works for you at all without
>>>> erroring out at cmake time. The C++ language was an absolute requirement 
>>>> for
>>>> 5.9.4.  The method used to find C++ had a different top-level (the project
>>>> command without any languages specified is the same as demanding C and 
>>>> C++),
>>>> but the underlying method (CMakeDetermineCXXCompiler) for finding the C++
>>>> compiler should be identical. Are you using the exact same generator and
>>>> environment variables for both PLplot 5.9.4 and PLplot svn trunk? The
>>>> generator and CXX environment variable will make a difference to whether 
>>>> you
>>>> find a C++ compiler or not.
>>> I believe everything is the same. I am using the CMake GUI configuration 
>>> utility and not the command line cmake (due to the apparent gdi32 issue). The 
>>> problem is that cmake-gui-plplot-5.9.4 considers my C++ compiler to be 
>>> findable/acceptable whereas cmake-gui-plplot-svn does not. Note that 
>>> cmake-gui-plplot-svn does find a Gnu CXX compiler but then errors out anyway. 
>>> Any ideas about what might have changed to lead to this difference would be 
>>> appreciated. I'd like to get Qt and PyQt working on the windows computer that 
>>> I have access to so I'll need to get past this C++ hang up (and/or figure out 
>>> the gdi32 thing so that I can use the command line version of cmake).
>> Try disabling the wingcc device to avoid anything to do with gdi32.  Does that
>> solve all your Windows build issues?
> 
> It looks like the problem is actually somewhere in the PLD_wxwidgets 
> logic. If I set PLD_wxwidgets=OFF then everything else seems to work 
> (for both plplot-svn and plplot-5.9.4).

I added a bunch of Message(STATUS "X") commands to wxwidgets.cmake and 
to FindwxWidgets.cmake. This leads me to believe that the problem is in 
the FIND_PATH(wxWidgets_ROOT_DIR .. command on line 388 in the 
FindwxWidgets.cmake module. Any suggestions about what to do/try next?

-Hazen

Hi,

I believe cmake can be told to be very verbose about its configuring.  
Don't have time now, but a quick search showed that

cmake --debug-output

might be of any help to you.

Regards,
Werner

On Jul 17, 2009, at 4:48 PM, Hazen Babcock wrote:

> Hazen Babcock wrote:
>> Alan W. Irwin wrote:
>>> On 2009-07-15 17:53-0400 Hazen Babcock wrote:
>>>
>>>> Alan W. Irwin wrote:
>>>>> [...]Furthermore, if you are still getting a warning (now) about  
>>>>> a missing C++
>>>>> compiler, I frankly don't understand why 5.9.4 works for you at  
>>>>> all without
>>>>> erroring out at cmake time. The C++ language was an absolute  
>>>>> requirement for
>>>>> 5.9.4.  The method used to find C++ had a different top-level  
>>>>> (the project
>>>>> command without any languages specified is the same as demanding  
>>>>> C and C++),
>>>>> but the underlying method (CMakeDetermineCXXCompiler) for  
>>>>> finding the C++
>>>>> compiler should be identical. Are you using the exact same  
>>>>> generator and
>>>>> environment variables for both PLplot 5.9.4 and PLplot svn  
>>>>> trunk? The
>>>>> generator and CXX environment variable will make a difference to  
>>>>> whether you
>>>>> find a C++ compiler or not.
>>>> I believe everything is the same. I am using the CMake GUI  
>>>> configuration utility and not the command line cmake (due to the  
>>>> apparent gdi32 issue). The problem is that cmake-gui-plplot-5.9.4  
>>>> considers my C++ compiler to be findable/acceptable whereas cmake- 
>>>> gui-plplot-svn does not. Note that cmake-gui-plplot-svn does find  
>>>> a Gnu CXX compiler but then errors out anyway. Any ideas about  
>>>> what might have changed to lead to this difference would be  
>>>> appreciated. I'd like to get Qt and PyQt working on the windows  
>>>> computer that I have access to so I'll need to get past this C++  
>>>> hang up (and/or figure out the gdi32 thing so that I can use the  
>>>> command line version of cmake).
>>> Try disabling the wingcc device to avoid anything to do with  
>>> gdi32.  Does that
>>> solve all your Windows build issues?
>> It looks like the problem is actually somewhere in the  
>> PLD_wxwidgets logic. If I set PLD_wxwidgets=OFF then everything  
>> else seems to work (for both plplot-svn and plplot-5.9.4).
>
> I added a bunch of Message(STATUS "X") commands to wxwidgets.cmake  
> and to FindwxWidgets.cmake. This leads me to believe that the  
> problem is in the FIND_PATH(wxWidgets_ROOT_DIR .. command on line  
> 388 in the FindwxWidgets.cmake module. Any suggestions about what to  
> do/try next?
>
> -Hazen
>


--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: smekal@...
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
        +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

On 2009-07-16 14:04-0700 Alan W. Irwin wrote:

>> On 2009-07-15 22:46-0700 Alan W. Irwin wrote:
>>
>>> [...]To summarize the choice we can have
>>> no soft landings or no cmake-gui.
>
> I have just committed (revision 10153) the hard-landing solution because
> there is no way I wanted to have both ccmake and cmake-gui provide broken
> language results such as found by Hazen and confirmed in detail by me.
>
> However, immediately after I did that commit, the CMake gurus on the CMake
> list came up with a temporary workaround for bug
> http://public.kitware.com/Bug/view.php?id=9220.  The workaround should
> provide a soft landing for both the missing and broken compiler cases which
> I think will work quite well.  However, the implementation of this idea (to
> run a simple cmake configuration from within cmake to check on each compiler
> in question) is non-trivial so it will take me a while to finish with this
> issue.
>
> So more later.

I believe I have now (revision 10157) finished this saga.  The new
soft-landing method (issue a warning message, disable that component of
PLplot, and continue) when compilers are missing/broken seems to work well.
For example, it appears to work both for cmake and cmake-gui. Please try it
out.

I have also enabled the D compiler by default since its examples are fairly
complete and the bindings and examples build without issues.

Previously, we were rather reluctant to enable a new language by default,
but now that a missing/broken compiler only causes a warning, I believe the
criteria for enabling a language by default do not have to be quite so 
severe as before.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Alan W. Irwin wrote:
> On 2009-07-16 14:04-0700 Alan W. Irwin wrote:
> 
>>> On 2009-07-15 22:46-0700 Alan W. Irwin wrote:
>>>
>>>> [...]To summarize the choice we can have
>>>> no soft landings or no cmake-gui.
>> I have just committed (revision 10153) the hard-landing solution because
>> there is no way I wanted to have both ccmake and cmake-gui provide broken
>> language results such as found by Hazen and confirmed in detail by me.
>>
>> However, immediately after I did that commit, the CMake gurus on the CMake
>> list came up with a temporary workaround for bug
>> http://public.kitware.com/Bug/view.php?id=9220.  The workaround should
>> provide a soft landing for both the missing and broken compiler cases which
>> I think will work quite well.  However, the implementation of this idea (to
>> run a simple cmake configuration from within cmake to check on each compiler
>> in question) is non-trivial so it will take me a while to finish with this
>> issue.
>>
>> So more later.
> 
> I believe I have now (revision 10157) finished this saga.  The new
> soft-landing method (issue a warning message, disable that component of
> PLplot, and continue) when compilers are missing/broken seems to work well.
> For example, it appears to work both for cmake and cmake-gui. Please try it
> out.
> 
> I have also enabled the D compiler by default since its examples are fairly
> complete and the bindings and examples build without issues.
> 
> Previously, we were rather reluctant to enable a new language by default,
> but now that a missing/broken compiler only causes a warning, I believe the
> criteria for enabling a language by default do not have to be quite so 
> severe as before.

I just tested this today with MinGW on Windows and the cmake GUI no 
longer crashes when run on plplot v10175. However... I have the standard 
MinGW C++ compiler which worked in the past for compiling PLplot but 
neither command line cmake nor gui-cmake will let me use it.

-Hazen

On 2009-07-22 22:51-0400 Hazen Babcock wrote:

> Alan W. Irwin wrote:
>> I believe I have now (revision 10157) finished this saga.  The new
>> soft-landing method (issue a warning message, disable that component of
>> PLplot, and continue) when compilers are missing/broken seems to work well.
> [...]I just tested this today with MinGW on Windows and the cmake GUI no longer 
> crashes when run on plplot v10175. However... I have the standard MinGW C++ 
> compiler which worked in the past for compiling PLplot but neither command 
> line cmake nor gui-cmake will let me use it.

Nobody can help you without details.  Therefore, could you be a lot more
specific?  What environment variables did you set (if any) to help cmake
choose the compiler? What were the cmake options that you used?  What
generator did you use? What was the complete cmake output that you got?
etc., etc.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Alan W. Irwin wrote:
> On 2009-07-22 22:51-0400 Hazen Babcock wrote:
> 
>> Alan W. Irwin wrote:
>>> I believe I have now (revision 10157) finished this saga.  The new
>>> soft-landing method (issue a warning message, disable that component of
>>> PLplot, and continue) when compilers are missing/broken seems to work 
>>> well.
>> [...]I just tested this today with MinGW on Windows and the cmake GUI 
>> no longer crashes when run on plplot v10175. However... I have the 
>> standard MinGW C++ compiler which worked in the past for compiling 
>> PLplot but neither command line cmake nor gui-cmake will let me use it.
> 
> Nobody can help you without details.  Therefore, could you be a lot more
> specific?  What environment variables did you set (if any) to help cmake
> choose the compiler? What were the cmake options that you used?  What
> generator did you use? What was the complete cmake output that you got?
> etc., etc.

Sigh, I always forget the details :). But I think I managed to figure 
out a few things. Maybe the problem is with the cmake command that is 
used to test the c++ compiler (the one that is run by 
language_support.cmake)? If I run the same command by hand:

xx\plplot_build\language_tests\CXX>"c:\Program Files\CMake 
2.6\bin\cmake.exe" .

I get:

CMake Error: CMake was unable to find a build program corresponding to 
"Visual Studio 6". CMAKE_MAKE_PROGRAM is not set. You probably need to 
select a different build tool.

Anyway, if I simply comment out the workaround_9220 section in c++.cmake 
then I can build PLplot with the Qt drivers and (untested) PyQt4 support 
so it all looks very promising.

-Hazen

Hi Hazen:

This is mostly addressed to you, but there is a question at the end for all
our developers.

On 2009-07-23 12:23-0400 Hazen Babcock wrote:

> [...]I think I managed to figure out a 
> few things. Maybe the problem is with the cmake command that is used to test 
> the c++ compiler (the one that is run by language_support.cmake)? If I run 
> the same command by hand:
>
> xx\plplot_build\language_tests\CXX>"c:\Program Files\CMake 2.6\bin\cmake.exe" 
> .
>
> I get:
>
> CMake Error: CMake was unable to find a build program corresponding to 
> "Visual Studio 6". CMAKE_MAKE_PROGRAM is not set. You probably need to select 
> a different build tool.
>
> Anyway, if I simply comment out the workaround_9220 section in c++.cmake then 
> I can build PLplot with the Qt drivers and (untested) PyQt4 support so it all 
> looks very promising.

Thanks for that information which I think contains a strong clue about what
is happening.  workaround_9220 does a small test run of the cmake command to
check the language support.  But when executing that test run, it just
invoked cmake with no generator specified.  That default won't work if an
overall generator is specified (which I assume it true in your case).  To
fix this I propagated the overall generator to the test run (revision
10176).

Please give that a try.

Note, there are quite a few ways within CMake to choose a compiler such as
specifying CMAKE_<lang>_COMPILER or CMAKE_<lang>_COMPILER_INIT.  There are
also a large plethora of ways to specify options for any given compiler.
workaround_9220 ignores all of that because I think it is too complicated to
propagate all the possibilities while still insuring a reliable result.
workaround_9220 should work fine if you use the default compiler for your
generator or if you have specified the compiler (and flags) with the
appropriate environment variable, e.g.,

export CXX="g++ -g -fvisibility=hidden"

since the environment variable should just propagate to the test cmake run.

I am inclined to simply say in the release notes that until CMake bug 9220
is fixed, we do not support any methods of specifying the compiler for the
soft landing logic other than using the appropriate environment variable.  I
could also implement a WORKAROUND_9220 option which defaults to ON, but
which in an emergency the user can set to OFF if he wants the most
comprehensive compiler detection but is willing to accept hard landings.

To all developers here, please let me know whether you think a
WORKAROUND_9220 option is overkill or not (i.e., do you think the vast
majority of our users use the environment variable approach for specifying
the compiler and compiler options).

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Alan W. Irwin wrote:
> Hi Hazen:
> 
> This is mostly addressed to you, but there is a question at the end for all
> our developers.
> 
> On 2009-07-23 12:23-0400 Hazen Babcock wrote:
> 
>> [...]I think I managed to figure out a few things. Maybe the problem 
>> is with the cmake command that is used to test the c++ compiler (the 
>> one that is run by language_support.cmake)? If I run the same command 
>> by hand:
>>
>> xx\plplot_build\language_tests\CXX>"c:\Program Files\CMake 
>> 2.6\bin\cmake.exe" .
>>
>> I get:
>>
>> CMake Error: CMake was unable to find a build program corresponding to 
>> "Visual Studio 6". CMAKE_MAKE_PROGRAM is not set. You probably need to 
>> select a different build tool.
>>
>> Anyway, if I simply comment out the workaround_9220 section in 
>> c++.cmake then I can build PLplot with the Qt drivers and (untested) 
>> PyQt4 support so it all looks very promising.
> 
> Thanks for that information which I think contains a strong clue about what
> is happening.  workaround_9220 does a small test run of the cmake 
> command to
> check the language support.  But when executing that test run, it just
> invoked cmake with no generator specified.  That default won't work if an
> overall generator is specified (which I assume it true in your case).  To
> fix this I propagated the overall generator to the test run (revision
> 10176).
> 
> Please give that a try.

It works now, thanks!

> Note, there are quite a few ways within CMake to choose a compiler such as
> specifying CMAKE_<lang>_COMPILER or CMAKE_<lang>_COMPILER_INIT.  There are
> also a large plethora of ways to specify options for any given compiler.
> workaround_9220 ignores all of that because I think it is too 
> complicated to
> propagate all the possibilities while still insuring a reliable result.
> workaround_9220 should work fine if you use the default compiler for your
> generator or if you have specified the compiler (and flags) with the
> appropriate environment variable, e.g.,
> 
> export CXX="g++ -g -fvisibility=hidden"
> 
> since the environment variable should just propagate to the test cmake run.
> 
> I am inclined to simply say in the release notes that until CMake bug 9220
> is fixed, we do not support any methods of specifying the compiler for the
> soft landing logic other than using the appropriate environment 
> variable.

Sounds reasonable to me. I almost never specify the compiler anyway and 
simply rely on cmake to pick up the right compiler.

-Hazen

Werner Smekal wrote:
> On Jul 15, 2009, at 7:14 PM, Hazen Babcock wrote:
>> (2) When I try to run a python example I get "ImportError: No module
>> named _plplotc". I have python2.6, numpy 1.3.0 and swig(swigwin?)
>> 1.3.39. Is there anything special that I need to do to use Python/ 
>> PLplot
>> on windows?
> 
> I once tested Python 2.4 on Windows and it kinda worked. Wait - I  
> wrote a message that days and you can read it here:
> 
> http://www.mail-archive.com/plplot-devel@...>
> 
> maybe this thread is of any help for you, keep us posted.

Renaming _plplotcmodule.dll to _plplotc.dll (located in 
c:\Python2.6\Lib\site-packages\) does not solve the problem for me. On 
linux the equivalent library is named _plplotcmodule.so so I'm not sure 
the name is the problem. Or maybe this name convention changed between 
python2.5 and python 2.6? I'm going to see if I can generate the 
bindings by hand and try to compare that to what the build system is doing.

-Hazen

On 2009-07-23 21:34, Hazen Babcock wrote:
> Alan W. Irwin wrote:
>> Hi Hazen:
>>
>> This is mostly addressed to you, but there is a question at the end for all
>> our developers.
>>
>>
>> I am inclined to simply say in the release notes that until CMake bug 9220
>> is fixed, we do not support any methods of specifying the compiler for the
>> soft landing logic other than using the appropriate environment 
>> variable.
> 
> Sounds reasonable to me. I almost never specify the compiler anyway and 
> simply rely on cmake to pick up the right compiler.
> 

Same here - on the Windows platform people seldom set environment
variables for such purposes (most people will rely on an installation
procedure to set the right values at start-up time)

Regards,

Arjen

Hazen Babcock wrote:
> Werner Smekal wrote:
>> On Jul 15, 2009, at 7:14 PM, Hazen Babcock wrote:
>>> (2) When I try to run a python example I get "ImportError: No module
>>> named _plplotc". I have python2.6, numpy 1.3.0 and swig(swigwin?)
>>> 1.3.39. Is there anything special that I need to do to use Python/ 
>>> PLplot
>>> on windows?
>> I once tested Python 2.4 on Windows and it kinda worked. Wait - I  
>> wrote a message that days and you can read it here:
>>
>> http://www.mail-archive.com/plplot-devel@...>
>>
>> maybe this thread is of any help for you, keep us posted.
> 
> Renaming _plplotcmodule.dll to _plplotc.dll (located in 
> c:\Python2.6\Lib\site-packages\) does not solve the problem for me. On 
> linux the equivalent library is named _plplotcmodule.so so I'm not sure 
> the name is the problem. Or maybe this name convention changed between 
> python2.5 and python 2.6? I'm going to see if I can generate the 
> bindings by hand and try to compare that to what the build system is doing.

I believe this is the problem for windows & Python versions > 2.4:
http://docs.python.org/whatsnew/2.5.html#ports

It says ".dll is no longer supported as a filename extension for 
extension modules. .pyd is now the only filename extension that will be 
searched for."

So I was able to get Plplot & Python to work by changing 
"_plplotcmodule.dll" to "_plplotc.pyd" (note "_plplotcmodule.pyd" does 
not work) and making sure the all the PLplot dll's are in my system path.

On windows we should probably check the version of Python and adjust the 
name accordingly. Also, we might consider installing the Python binding 
to "C:\PythonX\lib\site-packages\" instead of 
InstallPrefix\lib\site-packages.

-Hazen

On 2010-01-08 20:23-0500 Hazen Babcock wrote:

> So I was able to get Plplot & Python to work [on Windows] by changing
> "_plplotcmodule.dll" to "_plplotc.pyd" (note "_plplotcmodule.pyd" does
> not work) and making sure the all the PLplot dll's are in my system path.

Glad you discovered that.

>
> On windows we should probably check the version of Python and adjust the
> name accordingly.

The implication of some mailing list results I googled for after seeing your
above post, is that Windows Python has supported *.pyd for many versions. So
that python version check should not be needed.  Therefore, please go ahead
and change our build system so the Windows extension module name is always
_plplotc.pyd.

> Also, we might consider installing the Python binding
> to "C:\PythonX\lib\site-packages\" instead of
> InstallPrefix\lib\site-packages.

That's not what is done on the Unix side of things.  The
$prefix...site-packages installation location in that case allows our users to
build and install PLplot without root privileges.  I assume root privileges
mean nothing on the Windows side of things, but nevertheless I would prefer
to keep the Windows installation location consistent with the Unix
installation location.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Alan W. Irwin wrote:
> On 2010-01-08 20:23-0500 Hazen Babcock wrote:
> 
>> On windows we should probably check the version of Python and adjust the
>> name accordingly.
> 
> The implication of some mailing list results I googled for after seeing your
> above post, is that Windows Python has supported *.pyd for many versions. So
> that python version check should not be needed.  Therefore, please go ahead
> and change our build system so the Windows extension module name is always
> _plplotc.pyd.

Ok, I think I finally figure out how to do this. I left the Tk part 
alone as I'm not sure what is the correct renaming there.

-Hazen