PyQt4: QtHelp build issues
It all started with the fact that I wanted to install Python3 and Eric5 on my Kubuntu 12.04. Since only Eric4 is present in the repositories of "Pangolin", it was decided to put everything by hand from the source. In fact, in such an installation there is nothing difficult: I put Python3, then SIP , then PyQt4 , then QScintilla2 . At first glance, everything went smoothly. I quickly go to the directory with the distribution (I’m not afraid of the word) Eric5 and type in the cherished
What was my surprise when the script issued in the console
Funny, I think, may be the installer buggy? I launch in the same in the console the interpreter of the third python, I enter
')
It turns out that QtHelp is not really established. Since I had plenty of free time, I decided to just rebuild PyQt4, according to an old habit left over from using Windows. I started the assembly process and went to fry the dumplings, in anticipation of a delicious dinner and a speedy solution to the problem. He burned, ate, smoked, returned to the laptop, checked - the same, the problem remained.
I decided to appeal to the all-knowing Google. An omniscient problem ascertained, but did not give a solution. Someone has not decided it, someone just does not have it. Although it says here that the bug is fixed. Yes, it is corrected, aha.
There is nothing left but to pick up a scalpel and begin a deep investigation. The first thing I was interested in was the console output of the configure.py script, because it was he who was responsible for generating C ++ source codes, from which make would then assemble the binary library files. This script displays quite a lot of text, but only those parts that concerned the problematic QtHelp were important to me:
Here you can see that the script checked the ability to build the QtHelp module, but, apparently, the test was not successful, because QtHelp is missing from the final list of ready-to-build modules. Indeed, looking into the directory where PyQt4 is installed from, you will notice that the configure.py script for all Qt-modules created the same subdirectories (QtCore, QtQui, QtNetwork, etc.) containing the code in C ++. For all but QtHelp.
Here it would be necessary to look inside the script and see two things. First, what is the "modules will be built" list? Secondly, how the data gets there. I open configure.py in Kate, look for the cherished text and see this piece of code:
Yeah, the data is stored in the pyqt_modules list. How are they entered there? Surely, when checking the next module. Now you should search the script for the text “Checking to see if the <bla-bla-bla> module should be built ...”:
Bingo! This is just what you need! Here you can see that with a successful call to check_api (), the pyqt_modules list will be added with another value - the name of the module being checked. Initially, I wanted to pick up the check_api () call, and elementary logic suggested that this was the right way. However, I don’t know what pulled me off, but I decided to look at the code that calls the check_module () check procedure:
And then I noticed that QtCore is added to pyqt_modules without any checks. Thirst for experiment took her own: why not add QtHelp just like that? Indeed, in the case of Feil, I will not lose anything and continue to “tinker” further, and if I succeed, I will start working with my favorite IDE faster. No sooner said than done. I comment on the check_module ("QtHelp") call, I insert pyqt_modules.append ("QtHelp") in its place. I run the script again and in the Yakuake window I see the cherished
I check the availability of the QtHelp directory with source code - it is there. Next is the small thing: I run a long make and make install, and under a cup of hot coffee I wait for the build and installation to complete. Trying to reinstall Eric5 - voila! Everything was set, IDE works like a clock!
Of course, this is a pretty dirty hack. In an amicable way, it was still worthwhile to pick up the key to the door, and not to cut down that door with an ax. But similar actions were performed long ago by Peter the Great, who would forbid us now?
sudo python3 install.pyWhat was my surprise when the script issued in the console
Found PyQt4
Sorry, please install QtHelp.
Error: No module named QtHelpFunny, I think, may be the installer buggy? I launch in the same in the console the interpreter of the third python, I enter
')
>>> import PyQt4.QtHelp
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named QtHelpIt turns out that QtHelp is not really established. Since I had plenty of free time, I decided to just rebuild PyQt4, according to an old habit left over from using Windows. I started the assembly process and went to fry the dumplings, in anticipation of a delicious dinner and a speedy solution to the problem. He burned, ate, smoked, returned to the laptop, checked - the same, the problem remained.
I decided to appeal to the all-knowing Google. An omniscient problem ascertained, but did not give a solution. Someone has not decided it, someone just does not have it. Although it says here that the bug is fixed. Yes, it is corrected, aha.
There is nothing left but to pick up a scalpel and begin a deep investigation. The first thing I was interested in was the console output of the configure.py script, because it was he who was responsible for generating C ++ source codes, from which make would then assemble the binary library files. This script displays quite a lot of text, but only those parts that concerned the problematic QtHelp were important to me:
Checking to see if the QtGui module should be built...
Checking to see if the QtHelp module should be built...
Checking to see if the QtMultimedia module should be built...
...
These PyQt modules will be built: QtCore, QtGui, QtNetwork, QtDBus,
QtDeclarative, QtOpenGL, QtScript, QtScriptTools, QtSql, QtSvg, QtTest,
QtWebKit, QtXml, QtXmlPatterns, QtDesigner.Here you can see that the script checked the ability to build the QtHelp module, but, apparently, the test was not successful, because QtHelp is missing from the final list of ready-to-build modules. Indeed, looking into the directory where PyQt4 is installed from, you will notice that the configure.py script for all Qt-modules created the same subdirectories (QtCore, QtQui, QtNetwork, etc.) containing the code in C ++. For all but QtHelp.
Here it would be necessary to look inside the script and see two things. First, what is the "modules will be built" list? Secondly, how the data gets there. I open configure.py in Kate, look for the cherished text and see this piece of code:
sipconfig.inform("The Qt mkspecs directory is in %s." % qt_datadir) sipconfig.inform("These PyQt modules will be built: %s." % ", ".join(pyqt_modules)) sipconfig.inform("The PyQt Python package will be installed in %s." % opts.pyqtmoddir) Yeah, the data is stored in the pyqt_modules list. How are they entered there? Surely, when checking the next module. Now you should search the script for the text “Checking to see if the <bla-bla-bla> module should be built ...”:
def check_module(mname, incfile, test, extra_include_dirs=None, extra_lib_dirs=None, extra_libs=None): """See if a module can be built and, if so, add it to the global list of modules. mname is the name of the module. incfile is the name of the include file needed for the test. test is a C++ statement being used for the test. extra_include_dirs is an optional list of extra include directories. extra_lib_dirs is an optional list of extra library directories. extra_libs is an optional list of extra libraries. """ # Check that the module is enabled if we are not automatically enabling all # modules. if len(opts.enabled) > 0 and mname not in opts.enabled: return # Check the module's main .sip file exists. if os.access(os.path.join(src_dir, "sip", mname, mname + "mod.sip"), os.F_OK): sipconfig.inform("Checking to see if the %s module should be built..." % mname) if check_api(incfile, test, mname, extra_include_dirs=extra_include_dirs, extra_lib_dirs=extra_lib_dirs, extra_libs=extra_libs): pyqt_modules.append(mname) Bingo! This is just what you need! Here you can see that with a successful call to check_api (), the pyqt_modules list will be added with another value - the name of the module being checked. Initially, I wanted to pick up the check_api () call, and elementary logic suggested that this was the right way. However, I don’t know what pulled me off, but I decided to look at the code that calls the check_module () check procedure:
def check_modules(self): ... # Note that the order in which we check is important for the # consolidated module - a module's dependencies must be checked first. pyqt_modules.append("QtCore") check_module("QtGui", "qwidget.h", "new QWidget()") check_module("QtHelp", "qhelpengine.h", "new QHelpEngine(\"foo\")") check_module("QtMultimedia", "QAudioDeviceInfo", "new QAudioDeviceInfo()") And then I noticed that QtCore is added to pyqt_modules without any checks. Thirst for experiment took her own: why not add QtHelp just like that? Indeed, in the case of Feil, I will not lose anything and continue to “tinker” further, and if I succeed, I will start working with my favorite IDE faster. No sooner said than done. I comment on the check_module ("QtHelp") call, I insert pyqt_modules.append ("QtHelp") in its place. I run the script again and in the Yakuake window I see the cherished
Generating the C++ source for the QtHelp module...
Creating the Makefile for the QtHelp module...I check the availability of the QtHelp directory with source code - it is there. Next is the small thing: I run a long make and make install, and under a cup of hot coffee I wait for the build and installation to complete. Trying to reinstall Eric5 - voila! Everything was set, IDE works like a clock!
Of course, this is a pretty dirty hack. In an amicable way, it was still worthwhile to pick up the key to the door, and not to cut down that door with an ax. But similar actions were performed long ago by Peter the Great, who would forbid us now?
Source: https://habr.com/ru/post/145205/
All Articles