MacPorts custom installation prefix and precompiled binaries

[Joshua Root]

On 2022-8-7 18:29 , Jordan Ellis Coppard via macports-dev wrote:
> Hello,
> 
> 
> I read in the docs that if MacPorts is installed anywhere other than 
> /opt/local that precompiled binaries can not be used. I cannot find this 
> statement again so I am unsure if there was additional explanation for 
> why; so.. why?
> 
> I'd like to be able to use MacPorts at a custom prefix but still also 
> use precompiled binaries sometimes (particularly those using Rust) due 
> to the incredibly long compilation times.
> 
> 
> /Jordan

You may be remembering <https://trac.macports.org/wiki/FAQ#fromsource>.

Slight technicality, it's not that you can't use precompiled binaries 
with prefixes other than /opt/local, but rather you can only use 
precompiled binaries that were built for the prefix that you are using, 
and the ones on packages.macports.org were built for /opt/local.

The most immediate problem with installing a package built for one 
prefix into a different prefix is that simply extracting the package 
will give you files in the wrong location. Easily fixable, right? But 
then the files themselves can contain references to absolute paths that 
are in the wrong prefix, for example mach-o files record what they are 
linked with, scripts contain a shebang line that could say something 
like "/opt/local/bin/python3.10", paths to config files may be baked 
into executables, and so on.

All of this is fixable… given sufficient work. Some of it can be fairly 
simply automated, some would require extensive rewriting of upstream 
code. What you want is called "relocatable packages", and we currently 
have no support for that in MacPorts. If it were added, it could not 
automatically apply to all ports; we would have to manually flag which 
ports are relocatable, since while some software may build in a way that 
supports relocation out of the box, much will not.

- Josh