Fixing source-code bugs using MacPorts facilities.
Ian Wadham
iandw.au at gmail.com
Wed Jul 29 04:22:55 UTC 2020
> On 28 Jul 2020, at 8:06 pm, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Jul 27, 2020, at 01:53, Ian Wadham wrote:
>
>> I’m just saying that I can execute the file 'work/destroot/Applications/MacPorts/…/kpat’ instead of ‘/Applications/MacPorts/…/kpat’ — at the command-line of course.
>
> That executable may link with libraries installed by the port. If so, the executable would probably use the libraries at their installed location, not at their destroot location. If you have an old version of the libraries installed, that might cause problems. If you don't have the port installed at all, you'll get library not found errors. The application may also look for other data files at their installed location. All things considered, it's less problematic to install the port and then use the installed files.
>
Thanks, Ryan, point taken. I’ll be careful.
The risk is low, AFAICT, because all the source-code I am working with and dependent on, down to the level of Qt4, has been unchanged in MacPorts for several years, apart from tweaks to accommodate new versions of OSX. I am on High Sierra, but used to be on Lion back then.
Also, Ken, I have worked out a way of maintaining a git repository of the source code and edits that is external to MacPorts and entirely under my control, so the need to avoid “install” is not so great. The compromise is that, after a bunch of edits, I will be using a script I wrote called “./ship” to copy the changed files down into MacPorts’ work/<source-dir-name> area, after editing and before (re)building and testing.
Thanks very much to both of you, Ken and Ryan, for all your help.
All the best,
Ian W.
More information about the macports-users
mailing list