scopehal-apps macOS: "make install" is not putting data files in search path

In my ongoing adventure to get ngscopeclient to run from a global install location on macOS:

% ngscopeclient 
Assertion failed: ((0) && "Could not load font file!"), function AddFontFromFileTTF, file imgui_draw.cpp, line 2208.
zsh: abort      ngscopeclient

It looks like there are some fonts installed:

% ls /opt/homebrew/opt/ngscopeclient/share/ngscopeclient/fonts 
DejaVuSans-Bold.ttf DejaVuSans.ttf      DejaVuSansMono.ttf  License.html

I don't know exactly how font paths are derived, it seems to use the preferences system. I don't have any ~/.config/ngscopeclient/preferences.yml to try tweaking.

Oct 29 '23 21:10 rgov

Fonts, shaders, textures, etc. all use FindDataFile() in lib/scopehal/scopehal.cpp which checks g_searchPaths.

This is initialized by InitializeSearchPaths() in scopehal.cpp.

It looks like for macports it expects to find stuff in /opt/local/share/ngscopeclient or /opt/local/share/scopehal. How you ended up in /opt/homebrew/opt/ngscopeclient/share/ is anybody's guess but something is clearly wrong with the CMake install config.

Oct 29 '23 22:10 azonenberg

It looks like the font being passed is an empty string, maybe.

Process 60929 stopped
* thread #2, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x000000010007e258 ngscopeclient`ImFontAtlas::AddFontFromFileTTF(char const*, float, ImFontConfig const*, unsigned short const*)

(lldb)$ x/s $x1
0x16fdfeb48: ""

Oct 29 '23 22:10 rgov

How you ended up in /opt/homebrew/opt/ngscopeclient/share/ is anybody's guess but something is clearly wrong with the CMake install config.

Nope it looks like that's correct for Homebrew. The "Homebrew prefix" directory mimics the typical Unix layout, bin, lib, etc. Each package gets a link in <homebrew prefix>/opt to the package namespace. By default on ARM Macs, the default Homebrew prefix is /opt/homebrew, on Intel I think it's /usr/local, but it's customizable.

% ls -l /opt/homebrew/opt
total 0
lrwxr-xr-x  1 rgov  admin  22 Oct 29 13:42 0mq -> ../Cellar/zeromq/4.3.5
lrwxr-xr-x  1 rgov  admin  27 Oct 29 13:41 abseil -> ../Cellar/abseil/20230802.1
lrwxr-xr-x  1 rgov  admin  33 Oct 21 20:24 adwaita-icon-theme -> ../Cellar/adwaita-icon-theme/45.0
lrwxr-xr-x  1 rgov  admin  27 Mar 26  2023 aircrack-ng -> ../Cellar/aircrack-ng/1.7_1
lrwxr-xr-x  1 rgov  admin  23 Sep 17 01:26 ansible -> ../Cellar/ansible/8.4.0

Oct 29 '23 22:10 rgov

That's probably because FindDataFile() is failing, and we're not catching the error immediately.

But you're going to keep hitting this issue all over the place with every data file it tries to load. The root cause is still that the files are not being installed in the search path. So maybe we need to add $homebrew/opt/ngscopeclient to the search path list? How does one get the Homebrew prefix if it's not /opt/homebrew? I guess we can try and extract this from the application binary path?

Oct 29 '23 22:10 azonenberg

You can run brew --prefix ngscopeclient but that's going to be slow. It seems unusual that the app has to have special cases for MacPorts, etc.

I applied this patch and now I can launch it:

    # Patch search paths for Homebrew prefix #624
    inreplace "lib/scopehal/scopehal.cpp",
      'g_searchPaths.push_back(binRootDir + "/share/ngscopeclient");',
      'g_searchPaths.push_back(binRootDir + "/../share/ngscopeclient");'

It seems like if MacPorts is creating .../bin/share/ngscopeclient it is not following conventions that I typically see.

Oct 29 '23 22:10 rgov