Hi Ryan. Thanks very much for the info. I managed to solve that problem by adapting the code you pointed to.
Now I have another issue: after installation the port is flagged as broken with the following message. > sequelpro-devel is using libstdc++ (this installation is configured to use > libc++) As I understand it, the reason is that Sequel Pro contains a vendored binary framework that links to /usr/lib/libstdc++.6.dylib. What can I do about this? The portfile is here: https://github.com/amake/macports-ports/blob/sequelpro/aqua/sequelpro-devel/Portfile Thanks, Aaron > On Jun 13, 2019, at 17:58, Ryan Schmidt <ryandes...@macports.org> wrote: > > On Jun 13, 2019, at 02:01, Aaron Madlon-Kay wrote: > >> I am working on a portfile for Sequel Pro (https://sequelpro.com/) and >> am reaching the limits of my understanding of the Xcode build system. >> >> Sequel Pro contains several framework subprojects, which get built >> along with the main target. If I build the project normally outside of >> MacPorts then the frameworks get built and placed alongside the app, >> but also copied to into the app at Sequel Pro.app/Contents/Frameworks; >> `otool -L` on the main binary shows they are relatively linked as e.g. >> @executable_path/../Frameworks/foo. >> >> However when I build in MacPorts, INSTALL_PATH is automatically set to >> ${applications_dir}, and this apparently causes the main binary to >> look for the frameworks at e.g. /Applications/MacPorts/foo instead of >> @executable_path/../Frameworks/foo. Thus when I destroot just Sequel >> Pro.app it can no longer find the framework and blows up on launch >> (plus MacPorts correctly detects it as a broken binary). >> >> What is the correct way to handle this? > > You're right about all this. The xcode portgroup mangles INSTALL_PATH, which > breaks some the ability of some projects with separate frameworks from tying > themselves together properly. I think the xcode portgroup probably should not > mangle INSTALL_PATH, but it's how the portgroup currently specifies where > things should be installed. Maybe there is a better way for us to do that but > I haven't looked into it, and we have to be careful making any changes to the > xcode portgroup since it so old and so many ports have been using it for so > long and probably relying on what it currently does. > > When I ran into this situation, I just forced the portgroup not to set > INSTALL_PATH. The portgroup doesn't expose that as a direct option, but ties > it to xcode.destroot.type. So I just cleared xcode.destroot.type and handled > the destroot phase manually: > > https://github.com/macports/macports-ports/commit/4abca81870598d46d90c32769ad72f447589179e > > https://trac.macports.org/ticket/56850#comment:1 > > > P.S: Remember to use email addresses at lists.macports.org, not the older > hostname you used which was deprecated in 2016. >
