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...
> On Apr 14, 2022, at 11:57, Richard L. Hamilton <rlha...@smart.net> wrote: > > 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. > > Not sure how executables and frameworks within app bundles in e.g. > /Applications/MacPorts could be handled with that. > >> On Apr 14, 2022, at 05:48, Ryan Schmidt <ryandes...@macports.org >> <mailto:ryandes...@macports.org>> wrote: >> >> On Apr 14, 2022, at 04:34, Peter Serocka wrote: >> >>> 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. >> >> 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. >> >> 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. >> >> 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. >> >> > > -- > eMail: mailto:rlha...@smart.net > <mailto:rlha...@smart.net> > > > >
