[PD] PD OSX packaging redux

[Hans-Christoph Steiner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Nov 9, 2005, at 12:00 PM, Lorenz Schori wrote:

> 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".

I am a big fan of Fink and use it quite a bit.  I just don't think that  
its the best way to distribute Pd on Mac OS X.  On reason is that I  
think we need to start thinking of all this code not as externals and  
plugins, but a platform like Java.  When you download Java, you don't  
download the language and the "externals" separately, even though it is  
a vast collection of objects written by many different people.

Without much effort, the Pd.app could be made much more friendly to CLI  
people.  Certainly it would take less time that creating fink or  
darwinports packages.  Its been on my TODO list for a long time, it  
just hasn't been a high priority.  On the most basic level, a Tcl  
script could be written which maintains symlinks in the standard UNIX  
locations (/usr/local/lib, ../bin, ../include  etc.).  These symlinks  
would then point to the contents inside the Pd.app.  There would be a  
menu option to run this script, or you could just run it from the  
command line.  Then you could have a Pd.app that is drag-n-drop  
installable, runnable from any location, and works for the CLI people.


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

Things are mostly already broken down into logical units.  Pd,  
externals, flext, those all have distinct build systems which are just  
called from packages/darwin_app/Makefile.  I have now been sponsored to  
make this build system cross-platform, and cross-packaging system even.  
  So after this is done, it will be easier to make fink packages,  
darwinports, RPMs, DEBs, gentoo packages, etc.  All with the huge  
benefit of having the exact same contents in every package across all  
platforms.

If you look at just your particular OS/package preference, you don't  
see the whole picture.

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

Its a big ugly tangle of code, differing coding styles, a myriad of  
build systems.  No matter how you package it or build it, its not going  
to be easy.

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

Packaging Pd in Fink and/or Darwinports are not new ideas, they are old  
ones.  We chose to go the Pd.app route because it provides the most  
flexibility and behaves the most like a native app, which is what  
almost all Mac OS X users want, this CLI guy included.

As I have said before, I am not going to stop anyone, but all I ask is  
that we spend our limited resources on other things besides reinventing  
the build system wheel.  Fink or Darwinports packages could be useful,  
so please at the very least, let's work together to have one system  
that can work for building.

.hc

>
> 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
>>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->  
> http://lists.puredata.info/listinfo/pd-list
>

________________________________________________________________________ 
____

"Computer science is no more related to the computer than astronomy is  
related to the telescope."
                                                           -Edsger  
Dykstra
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)

iD8DBQFDcoJ6N4PEFRUrWIsRAugBAJ44cbVLtvy+PtpcKYIy+gotFsllGwCgtZIm
a3TZg1GDVD0J6fWysSnlNZQ=
=stu9
-----END PGP SIGNATURE-----