Xcode INSTALL_PATH and framework paths

[Aaron Madlon-Kay]

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 <ryandesign at 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.
>