[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
x11/py-tk situation on macos
x11/py-Tk does not build on macos, but the problem might be more on x11/tk…
Initially x11/py-Tk had an explicit dependency on libx11 , corrected later  and finally removed .
The dependency of X11 or not is related to x11/tk headers.
x11/tk main header, tk.h, includes x11/xlib:
# include <X11/Xlib.h>
# ifdef MAC_OSX_TK
# include <X11/X.h>
The big problem is that Tk has on macos two backends:
- x11 oriented,
- quartz oriented (named "aqua" by Tk, macOS specific).
Whatever the backend you choose at compile time, tk.h includes X11 headers:
- In the x11 backend, Xlib.h is a reference to an external implementation of xlib;
- In the "quartz" backend, Xlib.h is a reference to a local header coming with Tk.
If you compile Tk with X11 backend on macos, py-Tk will should have a X11 dependency.
On the contrary, if compiled with "quartz" backend, py-Tk should not have a X11 dependency but Tk puts its "X11" local headers directly under X11 directory and tk.h cannot easily include Xlib local header.
Consequently, we have a name collision if we have some X11 related stuff on macos and we want to have Tk built with quartz backend.
The behaviour is known because we have a comment in the Makefile of x11/tk:
# IMPORTANT: This option should be enabled on a system without X11.
# Otherwise some X11 headers are installed and will break X11 compatibility.
Now the problem is that for x11/py-Tk, the dependency depends on tk backend.
If by default we build Tk with X11 backend, then we should have an X11 dependency for x11/py-Tk.
I have already submitted a patch upstream concerning the name collision with X11 headers because it affects all downstream (macports have patches to avoid the name collision typically) but upstream does not seem very reactive…
Note python proposes as installer Tkinter with Tk "quartz" backend on macos...
Does someone have ideas to unbreak x11/py-tk?
Main Index |
Thread Index |