I recently been able to successfully compile ROOT on windows 7 using the cmake build system. I have spent many hours trying to get PyROOT installed as well. I have Python 2.7.3 installed and enabled the cmake build option for building python. It has all worked fine. In my root installation directory within the bin subfolder I see libPyROOT.dll but no .pyd . From my understand these should be the same thing, so after creating a copy of the dll and renaming the extension to .pyd I added the ROOTSYS\bin ROOTSYS\lib in my PATH environment variable and also set PYTHONPATH to ROOTSYS\bin . I added the bin and lib to my python sys.path as well by adding a file to my site-packages folder.
According to my understand it should be working. Indeed I no longer receive an error saying libPyROOT not found and can create root objects. However if I try to draw a simple canvas the canvas immediately hangs. Similarly when drawing histograms it will display briefly but then become a hanging blank canvas.
Has the latest version of ROOT (5.34.04) been tested with PyROOT? I am on windows 7, I built the release version of ROOT 5.34.04 and I have Python 2.7.3 installed.
I would very much appreciate any help, I am attempting to support windows as an environment for a software package we are developing.
I have tried using Python 2.7.3, Python 2.6.6 (both 32-bit). I have tried both copying and renaming libPyROOT.dll to libPyROOT.pyd and copying libPyROOT.pyd from the windows .tar on the root download page. I grabbed the binary installation and installed that too, which works with Python 2.6.6 without the canvas hanging issue. Which is very strange! There must be a broken step in the cmake/MVSC2010 build process. Here are my exact steps:
With CMake and MSVC2010 (plus SP1) installed on Windows 7 64-bit, I configure my source directory and build directory in separate folders. I set my installation directory to the same as my build directory. CMake found Python 2.6.6 (32-bit) and has enabled the installation. I run configure and then generate for MSVC2010. Afterwards I click the ROOT.sln and open in MSVC2010. With the configuration as Release - Win32 I right click on the solution in the file tree and build it. After that is done I right click on INSTALL and build that as well. So now my build/installation is in C:\shared-sw\root and I can open my commandline, run thisroot.bat, and start root just fine.
Then I set PYTHONPATH=%ROOTSYS%/bin, open Python2.6.6 and try the following
from ROOT import gROOT, TCanvas, TH1F
gROOT.Reset() #I tried with and without this
c1 = TCanvas(‘c1’, ‘Test Canvas’, 200, 10, 700, 700)
And the canvas opens, draws, and immediately hangs preventing any further input.
I hope someone can provide insight on what is going on, this is very frustrating.
can’t be of much help (neither experience with CMake and no access to a Windows machine), but yes, v5-34-04 has been tested with PyROOT (there are nightly tests running, which include tests of the startup of the GUI thread).
In the past, we’ve had issues with feeding GUI events on Windows. Last I checked it was solved, thanks to Bertrand).
If there is a build- or python-specific issue that could cause the problem, then the best I can think of, is that an exception is raised on the GUI thread and silently absorbed. You can find _processRootEvents() in ROOT.py and trace its execution.
Other than that, does the application you want to run on Windows need both the GUI and the prompt? If only the GUI, you can drive the GUI with an event loop from the same, main, thread, which guarantees no dead locks.
Again, sorry, no Windows access here, so it’s virtually impossible to do much as than guess/speculate …
It is odd that there is no libPyROOT.pyd created through this build method. Is it correct to assume that copying/renaming libPyROOT.dll to libPyROOT.pyd would fix any potential problem from the original *.pyd not being there?
yes; IIRC, the normal build script (configure/make/make install) does a copy.
root_test.py(2): c1 = TCanvas('c1', 'new tcanvas', 200, 10, 700, 600)
ROOT.py(321): while controller.keeppolling:
Python/ROOT seems to be hanging inside gSystemProcessEvents(). I haven’t seen anyone on the web who has tried using pyroot with the cmake build method, obviously something is broken but I’m only starting to learn how cmake works and my knowledge of how visual c++ works is minimal.
If you ideas on what could contribute to gSystemProcessEvents() hanging (or how to see what happens inside) I’ll take another look. Can this issue be flagged to the person(s) developing the cmake installation, or should I submit a bug report? Unfortunately I do require both the GUI and the prompt.
For what it’s worth I really think cmake is the way to go, cygwin is such a pain to setup and use.
if it hangs in ProcessEvents(), that typically is an issue with the event handler, but as per above, I thought that was fixed quite some time ago. If I have to guess for a problem related to the build system, my question would be whether Windows still has different runtime libraries for single and multi-threaded? (It used to; but the last time I used Windows was sometime during the Stone Age, so it may have changed.)
Other than that, it’s pretty hard to imagine the build system being responsible. But for the .dll -> .pyd at least, a bug report on https://savannah.cern.ch/projects/savroot/ would be warranted.