Sorry for slow reply, and for the large amount of terminal output here.
So, I tried what you suggested, and encountered the error documented here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892237 .
Seeing as this was fixed in a new wxPython release, I thought I’d try building 4.0.6 instead. When I tried the build_py command for that, I instead got this error, the causes of which I am uncertain:
[ 11/868] Linking build/waf/3.7/gtk2/siplib.cpython-37m-i386-cygwin.dll [ 12/868] Compiling sip/cpp/sip_corewxMemoryBuffer.cpp [ 15/868] Compiling sip/cpp/sip_corewxAccessible.cpp [ 16/868] Compiling sip/cpp/sip_corewxMaximizeEvent.cpp sip/siplib/apiversions.c.1.o: In functionsipInitAPI’:
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/…/…/…/…/sip/siplib/apiversions.c:132: undefined reference to
PyCFunction_NewEx' /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/../../../../sip/siplib/apiversions.c:135: undefined reference toPyDict_SetItemString’
sip/siplib/apiversions.c.1.o: In function
sipGetAPI': /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/../../../../sip/siplib/apiversions.c:189: undefined reference toPyArg_ParseTuple’
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/…/…/…/…/sip/siplib/apiversions.c:199: undefined reference to
PyLong_FromLong' /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/../../../../sip/siplib/apiversions.c:194: undefined reference to_imp__PyExc_ValueError’
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/…/…/…/…/sip/siplib/apiversions.c:194: undefined reference to
And so on - the output scrolls a really long way. I do have python3-devel installed, but it sounds like it’s not finding the library to link to or something. Can I specify it manually?
On Monday, June 10, 2019 at 11:18:23 PM UTC+1, Robin Dunn wrote:
On Monday, June 10, 2019 at 10:11:12 AM UTC-7, Hamish McIntyre-Bhatty wrote:
On Thursday, May 30, 2019 at 6:45:26 PM UTC+1, Robin Dunn wrote:
On Thursday, May 30, 2019 at 4:29:42 AM UTC-7, Hamish McIntyre-Bhatty wrote:
Update: Looks like it’s being included when SIP generates the files for example this can be found at the top of sip_core_ScrolledWindowsBase.cpp:
And so on. Is there a way I can configure SIP to avoid this?
I think the problem is happening before the SIP step. To verify, look in the generated files in sip/gen/*.sip. They probably already have the full path instead of just <wx/whatever.h> inside the generated %TypeHeaderCode blocks. If so, then it’s likely the ‘dox’ step that is incorrect. The *.sip files are generated by the ‘etg’ step, but for the most part it just pulls the include file paths directly from the XML files produced by doxygen.
Yes, you’re right, the %TypeHeaderCode blocks also have this issue.
What should I check next? I’m not very familiar with wxPython’s source tree and build system, so I feel I’m getting way out of my depth now!
If you’re working from a wxPython tarball (rather than a git checkout, for example) and you don’t need to make changes to the etg scripts or other code gen inputs, then you shouldn’t need to run the code generation steps as it’s all there already. So I would try just the “python3 build.py build_py --use_syswx --gtk2” command you mentioned in the first message.
If you do need to make changes that require the code to be regenerated then you’ll want to look at how build.py sets things up to run the regen.sh script, which is where doxygen is run. IIRC, Doxygen makes some assumptions about the location of the header files based on the current working directory, or something like that.