Thanks, Craig. 

By “non-standard, non-root locations” I was trying to reflect on my experience 
on some of the open-source packages that I frequency use on Mac OS in an app 
form. For example, Gmsh (http://gmsh.info <http://gmsh.info/>), deal.ii 
(https://www.dealii.org/download.html) and sage 
(http://www.sagemath.org/download.html) all provide .app bundles that I can put 
anywhere in my drive and they work. Note that gmsh has a GUI and deal.ii is a 
terminal app. 

What I have in mind is something similar to deal.ii (which uses cpack to create 
the bundle). 

You are right about the benefits of keeping a single location, say /opt/manav, 
but writing to that location would require someone to have root access. This is 
my constraint. 

-Manav

> On Jul 20, 2018, at 2:02 PM, Craig Treleaven <[email protected]> wrote:
> 
> My understanding is that dylibbundler is only for making double-clickable Mac 
> apps.  Perhaps I’m wrong.
> 
> When you say "I need these to work in non-standard, non-root locations”, what 
> is it that you are concerned about?  
> 
> If you create an installer with MacPorts, the user is going to need an 
> administrator password successfully deploy the software.  After that, the 
> user should be able to run your program from the Terminal with any userid.  
> It will be more convenient if they modify their PATH to include the location 
> your software is installed into.  For example, if you use the prefix 
> ‘/opt/manav’ when creating your installer, they will likely need to add 
> ‘/opt/manav/bin’ to their PATH.  That’s it.  You won’t have to mess around 
> with fixing up embedded paths—they remain the same from build system to 
> deployed software.  
> 
> Craig
> 
>> On Jul 20, 2018, at 2:24 PM, Manav Bhatia <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> No GUI. My app is a terminal application with plenty of dependencies. My 
>> users are at places and on systems without root access. 
>> 
>> I am not sure what the best approach is here, but I am looking at various 
>> options where I can distribute precompiled binaries. 
>> 
>> Dylibbundler sounds interesting but I have no experience to try to judge its 
>> limitations. 
>> 
>> I am also looking at CPack (from cmake), which seems to have some promise as 
>> it is cross-platform compatible, so I can use the same cmake configuration 
>> script to create bundles on Mac and Linux. 
>> 
>> I need these to work in non-standard, non-root locations. 
>> 
>> This should not be so difficult. 
>> 
>> -Manav
>> 
>> Sent from my iPhone
>> 
>> On Jul 20, 2018, at 1:01 PM, Craig Treleaven <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>>> Others will have to advise you on dylibbundler; it doesn’t do what I need 
>>> so I’ve never used it.
>>> 
>>> Does your app provide a Mac gui?  Otherwise, it doesn’t make sense to 
>>> create an app bundle.
>>> 
>>> Craig
>>> 
>>>> On Jul 20, 2018, at 11:03 AM, Manav Bhatia <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> 
>>>> I typically do:
>>>> 
>>>> $ port install openmpi-clang hdf5 eigen boost 
>>>> 
>>>> before building my application. This installs (a lot of) dependencies, 
>>>> including gcc. 
>>>> 
>>>> Thanks for pointing me to dylibbundler. I was not aware of that. I will 
>>>> look into the details of this package. 
>>>> 
>>>> Will this be able to take ports installed in a default /opt/local location 
>>>> and pack them in an app bundle? 
>>>> 
>>>> -Manav
>>>> 
>>>>> On Jul 20, 2018, at 9:53 AM, Craig Treleaven <[email protected] 
>>>>> <mailto:[email protected]>> wrote:
>>>>> 
>>>>>> On Jul 20, 2018, at 8:51 AM, Manav Bhatia <[email protected] 
>>>>>> <mailto:[email protected]>> wrote:
>>>>>> 
>>>>>> Thanks. 
>>>>>> 
>>>>>> I saw some instructions related to octave that describes creations of an 
>>>>>> app bundle that can be put anywhere: 
>>>>>> https://wiki.octave.org/Create_a_MacOS_X_App_Bundle_Using_MacPorts 
>>>>>> <https://wiki.octave.org/Create_a_MacOS_X_App_Bundle_Using_MacPorts>
>>>>>> 
>>>>>> One of the commands they used is install_name_tool: 
>>>>>> install_name_tool -change /opt/local/libiconv.2.dylib 
>>>>>> @executable_path/../lib/libiconv.2.dylib Octave-3.7.0+
>>>>>> 
>>>>>> So, if I only keep the specific header files and relevant dyld files, 
>>>>>> with enough care something like this should be possible (?). 
>>>>>> 
>>>>>> -Manav
>>>>>> 
>>>>> 
>>>>> Creating a Mac application bundle is a somewhat different objective from 
>>>>> what I thought was your stated goal.  You haven’t said what you want to 
>>>>> package.
>>>>> 
>>>>> If it is appropriate to package your app as an app bundle, then perhaps 
>>>>> dylibbundler is what you need.  Check ‘port info dylibbundler’ and ‘port 
>>>>> gohome dylibbundler’.
>>>>> 
>>>>> Craig
>>>> 
>>> 
> 

Reply via email to