> From what I can remember, what made this possible was: > - Separate and unique naming of KDE and Qt libraries, with links such as > qt3.so > to the latest versions of the basic XXX 3 and XXX 4 libraries and > binaries. > - Separate areas in $HOME (equivalent to $HOME/Libraries/Preferences) for > keeping users' settings and work files. > - Separate areas for other files such as temp files and caches. > - Environment variables to keep track of it all. > I am relying on memory, so if I have missed something, please excuse. Still, performing these steps are far from negligible, and some of them rely on paths which are outside of Macports, that applications use at runtime. It seems like overkill for ports which are becoming (or are already) deprecated.
> Is it possible to do something similar on Macports and remove the "conflicts > with" > restriction on KDE 3 and Qt 3, or is there some more fundamental problem, such > as qt4-mac is native to Mac OS X desktop and qt3 is not? Indeed, Qt3 depends on X11, while qt4-mac depends on aqua (native). There is also a qt4-x11, but its version is rather behind, and its build fails last time I tried. Some conflicts in the dependencies may thus also be expected, as pointed out. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
