[PD] PD OSX packaging redux

[Lorenz Schori]

so let's not mix things together.
1. frank and then david thought about packing pd into fink. i would  
like to see it in darwinports. for dependency tracking, installing  
externals which rely on shared libraries (i prefer them over static  
linked ones) one of those package systems just _is_ better. i stated  
in my first answer to david: "i'm just thinking about how pd on mac  
could be more conveniant for (doubleclick)users AND (cli)developers".
2. i did read man otool, man install_name_tool, man dyld, man ld and  
many others, i know much about shared/static libraries, bundles and  
frameworks and i did investigations on the web and in the list  
regarding a cleaner and more flexible way to build and maintain  
pd.app. i know the problems with packing pd and tracking dependancies  
and i know the buildsystems and...
3. [rant here] i don't like the darwin_app makefiles. i suggest you  
to break things down into logical units, e.g. throw out the html  
docs, do externals seperate, just concentrate on the objective  
(building the pd.app). so poeple looking at it will find what they  
need. [end of rant]. i don't want to discuss this further because i  
don't have the time to work on a better system.

don't get me wrong. i like yours and hans work but i'm just a bit  
annoyed that i have to mess around with too much build related  
problems if i want to change just little things in pd.

keep up the work but please be a bit open for new ideas and try to  
understand them...

lorenz


Am 09.11.2005 um 17:34 schrieb james tittle:

> On Nov 9, 2005, at 6:28 AM, Lorenz Schori wrote:
>> Am 09.11.2005 um 12:15 schrieb David Plans Casal:
>>
>>>> just think about this possible scenario:
>>>> 1. install pd + externals via package management (fink/darwinports)
>>>
>>> +1
>
> ...it wouldn't be hard to add a pd package to fink or darwinports,  
> but I don't think there's that much demand since there's already  
> several app bundles available...plus, who's got the time to make  
> packages for the dependencies of all the externals?
>
>>>> 2. run a script which grasps all the abstractions  
>>>> and .pd_darwins + docs.
>>>
>>> From where? I mean once you've installed with 'fink install pd'  
>>> or whatever, how do you envision running the script?
>>
>> i imagine something like pdadmin or phps pdmkapp you mentioned below.
>
> ...have ya'll not heard of the "package" build system in cvs?  It  
> does exactly this, for an app bundle...
>
>>> I was just thinking of one big Pd.app being dumped in / 
>>> Applications, with all needed externals pre-built.
>>
>> cool. this will be step 1.
>
> ...again, this has been done:  I can think of at least three  
> available:  mine (pd++.app), Hans', and ben's pixeltango...why re- 
> invent the wheel?
>
>>>> 3. run a script which grasps all the needed dylib's from the  
>>>> distribution (using "otool -L")
>>>
>>> Interesting.
>>
>> but sadly not quite straight forward. see http://qin.laya.com/ 
>> tech_coding_help/dylib_linking.html
>
> otool won't help much here beyond telling you what is being linked  
> against:  your friend is "install_name_tool", ask man for info...
>
>>>> this mechanism could be extended to provide a way to easily  
>>>> deploy custom Pd.app which just include needed externals and  
>>>> possibly have patches autostarted.
>>>
>>> Ok so we could have CLI instructions such as:
>>>
>>> 'pdadmin myinstallation'
>>>
>>> And output would be a myinstallation.app/ directory with pd  
>>> binaries, externals, etc? I guess CLI options to that would be  
>>> nice. A bit like Django and Rails options.
>>>
>>> Not sure though, how one would go about building this.
>>
>> me neither. just ideas.
>>
>>>
>>>> @hans+james. this is no rant against you and i don't want to  
>>>> just create another build system. i'm just thinking about how pd  
>>>> on mac could be more conveniant for (doubleclick)users AND (cli) 
>>>> developers :)
>>>
>>> And yes, why not rely on the current build systems?
>>
>> don't know how they will go with fink.
>
> ...I use fink for the dependency libs right now...again, I  
> understand and encourage your interest, but spend some time looking  
> thru the archives here, and you'll see that this has been well  
> covered over the last few years...
>
> l8r,
> james
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: Signierter Teil der Nachricht
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20051109/385a0bf1/attachment.pgp>