<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">app bundles produced by Xcode are much more "controlled" than usual packages that use all kinds of build/make tools... It is virtually impossible to impose the use of @loader_path from the "top" level where MacPorts is operating...<div><br class=""><blockquote type="cite" class=""><div class="">On Apr 14, 2022, at 11:57, Richard L. Hamilton <<a href="mailto:rlhamil@smart.net" class="">rlhamil@smart.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Would use of @loader_path as in @loader_path/../lib or whatever when linking binaries (and something similar for linking between libraries within MacPorts) not be a big part of making it so the executables and libraries didn't embed where the tree lived? There would doubtless be other changes to make it possible to move /opt/local without breaking pre-built binaries, but that might be a big part of it. And it could be started one port at a time, long before everything needed to be done to make that possible.<div class=""><br class=""></div><div class="">Not sure how executables and frameworks within app bundles in e.g. /Applications/MacPorts could be handled with that.</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Apr 14, 2022, at 05:48, Ryan Schmidt <<a href="mailto:ryandesign@macports.org" class="">ryandesign@macports.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Apr 14, 2022, at 04:34, Peter Serocka wrote:<br class=""><br class=""><blockquote type="cite" class="">Sure. On the other hand -- let me suggest MacPorts to adopt OS/architecture-specific prefixes by default. Transitions will benefit, in particular in cases where "some" ports are troublesome.<br class=""></blockquote><br class="">I don't think there's any chance of that happening now. MacPorts has used the /opt/local prefix for 20 years and I think you're the first person in that time to suggest changing it. There are many projects out there, and many web pages with documentation, that are already written with that prefix in mind.<br class=""><br class="">Even if we thought it would be a good idea to change it, if we wanted to change it for any existing users, we would have to develop an upgrade strategy for it. And we would have to recompile all of the binary archives we offer.<br class=""><br class="">Migrating to a new OS version or architecture would then become more complicated, as users would need to manually move configuration files and other data from one prefix to another.<br class=""><br class=""><br class=""></div></div></blockquote></div><br class=""><div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">-- <br class="">eMail:<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="mailto:rlhamil@smart.net" class="">mailto:rlhamil@smart.net</a></div><div class=""><br class=""></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""></div></div></blockquote></div><br class=""></body></html>