Added hexchat.py to the Visual Studio Python plugin project item list so it is tracked consistently in the Windows project metadata.
Added hexchat.py to the corresponding .vcxproj.filters entries under Source Files for IDE consistency.
Added a Python hexchat.py compatibility module and ensured it is installed alongside zoitechat.py/xchat.py, enabling import hexchat scripts to run.
Updated the Perl API layer to support HexChat naming by aliasing HexChat:: to ZoiteChat::, adding EAT_HEXCHAT to exported constants, and adding an explicit Perl shim module HexChat.pm.
Extended Perl XS constant registration to export EAT_HEXCHAT as a compatibility alias, and wired HexChat.pm into the embedded Perl module generation list so it ships with the plugin.
Kept the existing safe behavior intact: paths are only added if they exist and are not already in sys.path, so this broadens compatibility without duplicating entries.
existing sibling fallback (../python)
direct fallback (libdir/python)
AppImage-aware fallbacks under $APPDIR/usr/lib/zoitechat/python and $APPDIR/usr/lib/x86_64-linux-gnu/zoitechat/python.
Added guards so paths are appended only if the directory exists and is not already in sys.path, reducing duplicate/invalid entries while improving robustness across packaging layouts.
Updated the Python plugin Visual Studio project to also undefine _DEBUG and Py_DEBUG (in both Release|Win32 and Release|x64), alongside the existing Py_REF_DEBUG and Py_TRACE_REFS, to avoid pulling in debug-only Python refcount symbols during linking.
Updated the Windows Python plugin project file to explicitly undefine Py_REF_DEBUG and Py_TRACE_REFS in both Release|Win32 and Release|x64 compile settings, preventing the build from pulling in CPython debug-refcount import symbols that are missing from normal Python import libraries.
Updated the Python plugin Visual Studio project to define Py_NO_LINK_LIB in both Release|Win32 and Release|x64 configurations, so CPython headers won’t auto-link a debug import library like python314_d.lib.
Kept explicit linker input ("$(Python3Lib).lib") unchanged, so linking continues to use the configured Python library from project properties.
Python3Enabled (python executable + import lib + cffi)
PerlEnabled (perl executable + perl runtime DLL + gendef.exe)
InstallerEnabled (Inno Setup iscc.exe).
Updated the Python plugin project to compile only when Python3Enabled is true, and otherwise emit a clear skip message instead of failing prebuild/import steps.
Updated the Perl plugin project similarly to gate build steps on PerlEnabled and print a skip message when prerequisites are missing.
Updated the installer project so it only uses C++ targets when InstallerEnabled is true, with a fallback skip message when Inno Setup is unavailable.
The python plugin use weak references for hooks, which might let a
necessary object disappear if the callback of a timer hook unhooks
itself.
Signed-off-by: Celelibi <celelibi@gmail.com>
Python sometime calls flush() on sys.stdout or sys.stderr.
In particular, it might do so when an exception is raised. This fixes
the second error message that was generated in such cases.
Signed-off-by: Celelibi <celelibi@gmail.com>
* Make sure `help()` doesn't cause hexchat to hang
Replace `pydoc.help` with a copy of `pydoc.Helper` with an empty
`StringIO` instead of stdin
* Handle BytesIO vs StringIO on 2.7
Quick rundown of benefits:
- Much faster:
- Autotools (with autogen): 22 seconds
- Meson: 7 seconds
- Meson (with ccache): 2 seconds
- Simpler:
- ~1000 lines smaller
- Single simple language
- Potentially better Windows (Visual Studio) support
What is not done:
- Complete Windows support
- OSX support (easy)
Closes#2013Closes#1937Closes#1803
When hexchat is already installed into a non-default prefix, a new build
could pick up ${prefix}/include/hexchat-plugin.h from the installed
version instead of the local header, as configuration variables such as
$(GLIB_CFLAGS) would point to -I${prefix}/include.
Reordering the includes and moving -I arguments to CPPFLAGS prevents
this, as it ensures the local directories are always searched first.
This was no problem when compiling for /usr or /usr/local as these
directories in the compiler search path are always searched last.
Closes#1822
