nona in unexpected location

Asked by R. Padraic Springuel

I'm using Hugin 2016.0.0 on Mac OS 10.10.5 installed using MacPorts. This installation method places the command line tools in /opt/local/bin. However, when launching processes using the GUI apps, the program looks for the command line tools in the same location as the GUI apps by default. Now, while I've been able to correct this via the preferences for enblend and enfuse, I can't seem to correct this for nona. I.e. trying to stitch a project from PTBatchGUI tries to launch /Applications/MacPorts/PTBatchGUI.app/Contents/MacOS/nona instead of /opt/local/bin/nona. I've been able to bypass the problem by creating a symlink from where the GUI is looking to where nona actually is, but said solution is likely to be fragile and break when MacPorts updates hugin in the future. Is there a preference that I've missed that would allow me to specify the location of nona in a more stable manner (MacPorts doesn't erase preferences when updating a program)?

Question information

Language:
English Edit question
Status:
Answered
For:
Hugin Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
R. Padraic Springuel (rpspringuel) said :
#1

Something similar seems to be occuring with exiftool, which is installed as /opt/local/bin/exiftool-5.22 on my system (i.e. the PERL version number is appended). However, in this case the log file isn't descriptive enough for me to tell where it's looking for exiftool so I don't know where to put the symlink to get around this (/usr/local/bin doesn't work).

Revision history for this message
tmodes (tmodes) said :
#2

In our CMake build system there are 2 possibilities to build on Mac:
1. A *nix way: Here the tools are installed and search in a fixed path, which is given during building. (For the external tools, like enblend, enfuse, exiftool, also the PATH environment variable is taken into account to search for the program.)
2. Building an OS/X bundle. In this case all the tools are bundled into a bundled and searched in the bundled.

Here it sounds there is something mixed up. I don't know what the MacPort maintainer do to build it (which patches are applied and with which options it is build). So please report your problems to the MacPort maintainers.

Can you help with this problem?

Provide an answer of your own, or ask R. Padraic Springuel for more information if necessary.

To post a message you must log in.