conflict with macports

[Adam Dershowitz Ph.D., P.E.]

On Jun 12, 2014, at 4:20 PM, Daniel J. Luke <dluke at geeklair.net> wrote:

> On Jun 12, 2014, at 4:10 PM, Mojca Miklavec <mojca at macports.org> wrote:
>> 
>> On Thu, Jun 12, 2014 at 9:25 PM, Joshua Root wrote:
>>> 
>>>> I received the same email as you did.
>>>> I suggested that he could use MacPorts into /opt/z88 or something similar.  But, given this email chain, I will instead suggest using dylibbundler.
>>> 
>>> It's not clear exactly what they're doing that prevents them from
>>> installing into a different prefix.
>> 
>> Disclaimer: I don't know the project, but my guess is ...
>> 
>> Lack of manpower (and understanding about best packaging practice on
>> different OSes). It is also not impossible that they simply don't know
>> how to install MacPorts elsewhere.
> 
> they don't need to install macports anywhere else

I believe what Mojca is suggesting, as a possible easy solution for them is for the developer to install MacPorts into /opt/z88, for example.  Then to install the ports they need, and link their application against those.  Finally, they can ship the same installers that they have.  One for the application and another that will just copy stuff into /opt/z88.  That would mean that they don’t have to change much right away, and can co-exist on a user’s machine with MacPorts installed.  I have made this suggestion to them as well.


> 
>> Take a look at their sources, particularly at their Makefiles. Or take
>> a look at the manual to see installation instructions.
>> 
>> By far the easiest short-term solution would be to make a Portfile and
>> then advise everyone to use the package from MacPorts as opposed to
>> installing their binary package.
>> 
>> In the next step someone can help them rewrite the Makefiles. And then
>> fix the binary package, step by step.
> 
> they can copy the libs they want (and the libs that those libs use), put them somewhere else, and use install_name_tool to fix the path(s) embedded in the libs so that they still work.
> 
> Bonus points for putting them inside their app bundle (and extra bonus points for using the tool that was pointed out to help with this).
> 

And, I have now suggested using dylibbundler.  

I have also suggested that you MacPorts developers have tended to be very helpful to people trying to develop ports.  So, perhaps they will be willing to reach out some and provide more details, so the problem can be better understood.