[PD] Pd packaging on osx was: Re: [PD-announce] [osx] pd++0.39-1Beta available

[Hans-Christoph Steiner]

The point of the way that the Pd.app is structured now is that you are  
not supposed to edit it at all. You make all of your additions to  
folders like ~/Library/Application Support/Pd/Externals and  
~/Library/Application Support/Pd/Doc.  That way you can upgrade Pd  
without messing with your setup, among other advantages.

This has been discussed in the past a far amount.  If you are  
interested, I suggest checking out the archives.

Also, in my next release, I'll be enabling the new Plugins management  
feature that you'll see in the Info panel of the Pd.app.

.hc

On Oct 24, 2005, at 1:13 PM, Lorenz Schori wrote:

> hi
>
> different pd versions: actually i wonder how pd/linux deals with this  
> problem. does msp version look into other paths as devel? are they  
> configured at runtime? i thougth about an additional standard path in  
> osx determined at compile time from the version information (like  
> "~/Library/Application Support/Pd/0.39-msp/extra" +  
> "~/Library/Application Support/Pd/0.39-msp/doc").
> fink: i think it would be easy to just pack debians and throw it into  
> fink. for advanced users (with several pd versions/flavours) this  
> would be fine. however the advantage of the pd.app is that pd files  
> get double-clickable on desktop and messing around with the command  
> line will not be nessesary. i think for most osx users it would be  
> comfortable to just link the externals statically with the requred  
> libraries.
> flext: i don't know if this is possible and i'm not sure if this makes  
> sense: how about just linking flext statically into pd binary? if i  
> have to compile flext for each pd version/flavour anyway i don't see a  
> drawback to just include it (appart from eventual stability issues).
>
> lorenz
>
> Am 24.10.2005 um 17:33 schrieb Frank Barknecht:
>
>> Hallo,
>> Lorenz Schori hat gesagt: // Lorenz Schori wrote:
>>
>>
>>> it is certainly not the goal to make things more complicated nor to
>>> include less stuff. what i propose is just to move the externals out
>>> of the package into a more accessible, managable and natural (for osx
>>> users) place, plus to modularize externals a bit (standard/gem/pdp/
>>> flext/...). this way it will be easier to upgrade pd and different
>>> external packages independantly from each other.
>>>
>>
>> But is there a way to handle dependencies as cleanly as e.g. Debian
>> does it? For example you would need different flext packages for
>> pd-devel and ps-MSP, IIRC. Some externals which use private headers
>> may need to be recompiled for a a new upstream version. With a single
>> package it is easy for Mac users to get matching versions of
>> everything.
>>
>> I guess it would be the best to get in contact with the Fink team and
>> provide regular Fink packages of Pd and Pd externals?
>>
>> Ciao
>> --  
>>  Frank Barknecht                 _ ______footils.org_ __goto10.org__
>>
>> _______________________________________________
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->  
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->  
> http://lists.puredata.info/listinfo/pd-list
>

________________________________________________________________________ 
____

"[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it
away to benefit those who profit from scarcity."
                                                                          
        -John Gilmore