Thanks Grauw. Unfortunately Homebrew breaks many other things in my mac and I had to switch to MacPorts. But I found a way to have the debugger working without Homebrew.
First, the OpenMSX debugger is looking for QtCore in a rather odd place:
/usr/local/opt/qt5/lib/QtCore.framework/Versions/5/QtCore
This seems to be the only file needed for the debugger to start.
So I made a link from /usr/local/opt/qt5 to the place qt is installed in my Mac.
cd /usr/local
sudo mkdir opt
cd opt
sudo ln -s /opt/local/libexec/qt5 qt5
or more offcially:
sudo ln -s /Library/Frameworks/QtCore.framework/Versions/5 qt5
Should work for most people, assuming Qt was installed in the machine.
cool to see you've managed to make it work. But its rather cumbersome to download 16GB of software and still have to patch it around...
True, that worked for me because I use Qt for other development as well.
And just a handful of files in the Qt distro are really needed for the debugger.
In the end I feel that as OpenMSX seems to use Tcl, a lean debugger interface written in Tk would the be simplest option. And it would work on any environment OpenMSX is ported without any extra config needed. It wouldn't look or perform any worse than the current interface. Could even be made part of OpenMSX itself.
openMSX currently doesn't have any dependency on Tk, only on the Tcl library. So, on Windows for instance, we only link statically to libtcl, and not libtk.
Hi, Manuel. Thanks for your comment. We were discussion the places that the debugger searches for Qt (in MacOS). The way it is set it pretty much forces you to install Qt with homebrew. Would it be possible to add more flexibility to that mechanism so normal/direct Qt installs (/Library/Framework/...), or MacPorts Qt installs would also be found?
Thanks.
I have no idea, I do not have a Mac myself and I'm not knowledgeable on building stuff for Mac OS X. Perhaps someone can help here?
To be clear, we're talking about running the daily build of the openMSX Debugger, not building it from source, correct?
The most reliable way to handle it would be to package the required Qt components into the Debugger's .app folder. The problem is that I don't have a working Mac anymore, so while I can advise people who want to implement that, but I can't implement or test it myself.
Yes! I can help with that but I'll need some handholding. The other way is that Qt can only be installed in a handful of places. It is either Homebrew, MacPorts or the Qt install. I imagine that there should be a way to specify a handful of paths where Qt core has to be searched when building the debugger.
Yes! I can help with that but I'll need some handholding. The other way is that Qt can only be installed in a handful of places. It is either Homebrew, MacPorts or the Qt install. I imagine that there should be a way to specify a handful of paths where Qt core has to be searched when building the debugger.
@openMSX team,
Isn't there a way to try loading from one of the three possible locations above before throwing a nasty error message + memory dump right at user's face?
@Edevaldo,
Since you look closer to a Qt expert: Is there a system variable set by Qt installer (and of course both brew and MacPorts)
that tells where Qt files are?
Technically, searching for Qt in multiple places might be feasible: macOS probably has an equivalent of LD_LIBRARY_PATH, which could be set from a wrapper script. However, what if there are multiple versions of Qt installed and one is too old for the debugger? To make it work reliable in every situation is not so simple.
Also, requiring the user to install libraries at all before they can run an application is not really what macOS users expect. So I would much prefer that the Debugger comes with all the libraries it needs, either linked statically to Qt or with the Qt dylibs inside the .app folder.
There is Qt documentation about deploying to macOS: several options are mentioned, including static linking and adding dylibs to the .app folder. However, I don't know if for example the Homebrew build of Qt includes static libraries or whether we'd have to build those ourselves. Also it would be interesting to test what the size difference is between static linking and including the required Qt components as dylibs.
Also, requiring the user to install libraries at all before they can run an application is not really what macOS users expect. So I would much prefer that the Debugger comes with all the libraries it needs, either linked statically to Qt or with the Qt dylibs inside the .app folder.
Sometimes when we're devs or even just "IT guys" we assume some tasks are too simple to bother simplifying, being one of them installing something to make some other thing work. "Of course it is simple, it's our every day bussiness!" but not every MSX lover (being either Windows, Linux or Mac user) really know how to deal with...
I wish I could help you guys on this some way.