It’s been 6 months so I’ve forgotten some details, but I can look later this evening.
My recollection is that I had to tweak a couple of symlinks, but mostly everything just worked. With that said, my needs were pretty simple. I needed a working Rust and Cargo for ports that depended on them inside my custom install location, but I don’t actually use Rust or Cargo there directly. > On Aug 12, 2024, at 6:24 AM, Sergio Had <vital....@gmail.com> wrote: > > Does self-referencing work in this case? Say, gcc or boost have gazillion > headers some of which may include other internal to the port headers. I am > also not sure if baked in dylib paths follow through symlinks. > > Serge > On Aug 12, 2024 at 20:28 +0800, Frank Stock <fst...@bytelightning.com>, wrote: >> Somewhat similar situation 6 months ago. Maybe its an idea that will help >> with what you want. >> I needed a MacPorts install with a custom prefix on a 10.13.x machine. >> Custom prefix means you cannot use pre-built binaries, and at the time Rust >> and Cargo were not buildable on that platform. >> >> I ended up installing a standard MacPorts installation containing Rust and >> Cargo (which used the pre-built versions of those because they were in the >> standard location). >> Then because what I needed in the custom prefix depended on, but did not >> include, Rust or Cargo, I was able to simply symlink those into my custom >> prefix and get everything built that I needed. >> >> -Frank >> >>> On Aug 11, 2024, at 2:27 PM, Daniel J. Luke <dl...@geeklair.net> wrote: >>> >>> On Aug 11, 2024, at 4:15 PM, Sergey Fedorov <vital....@gmail.com> wrote: >>>> >>>> For testing purposes, I want to use an existing MacPorts installation with >>>> another local system (same major darwin version, different minor). Is >>>> there a way to do that besides actually copying the whole tree (or >>>> reproducing it via installing)? >>>> >>>> Specifically, I want to try building a few specific ports, but I neither >>>> want to build everything from scratch (that will take days of compilation) >>>> nor ditto a multi-gigabyte tree (that is feasible but inconvenient). >>>> Simply symlinking /opt/local from a volume with MacPorts into /opt/local >>>> on a system of interest does not work correctly.\ >>> >>> https://trac.macports.org/wiki/howto/ShareArchives2 might help (you'll copy >>> files over but won't have to build from scratch. >>> >>>> Any alternatives which will actually work as intended? I.e. I want a clean >>>> system to use /opt/local from another volume. >>>> Or can I configure MacPorts on the system of interest to use a prefix >>>> pointing to ${another_local_volume}/opt/local? >>> >>> Yon can build base from source and point macports point to a different >>> directory. >>> >>> I had a version of MacPorts working where /opt/local was a symlink some >>> time ago (I had a local patch to fixup some of the problems, but I can't >>> find it now). IIRC setting prefix in macports.conf made things mostly work. >>> >>> -- >>> Daniel J. Luke >>> >>
