[PD] Re: [PD-dev] CVS now handles binaries

[Adam Lindsay]

Hi Chris,

I'm glad other Mac people are thinking about this. My concern was 
primarily with packaging binaries of *externals*, which, looking back, 
wasn't clear in my last email. That changes things, but you bring up a 
lot of points worth talking about anyway.

I hope people don't mind that I've cc'd this message to the general 
pd-list, since it's a bit more, uh, general.

On Friday, December 6, 2002, at 06:31 PM, chris clepper wrote:
>> I've been giving some thought to that on the OSX side, mostly with
>> regards to the packaging system. I'm not sure what's the most 
>> convenient
>> way to make installable packages on the MacOSX side of things. Apple's
>> .pkg is attractive, but the current package format doesn't seem to be
>> very manipulable by the command-line.
>
> why even bother with a packaging system for the binary?  how about 
> this for an install on OSX:
>
> step one: download binary
> step two: un-tar/zip/stuff downloaded file
> step three: open pd folder and double click on CLICK_ME_TO_RUN_PD 
> smiley face icon

> for step three to happen, write a pdstart.command that has ./pd 
> -options and put it in the pd/bin dir.  make an alias to it with that 
> big smiley face icon at the root of the pd folder.

Can you believe I hadn't considered that? Yes, that would be a nice, 
friendly, easy way of approaching things.

> i don't think you can assume that the typical Mac user uses the 
> command line at all, so OSX apps should take that into account.  the 
> above approach seems to be in line with most free/shareware 
> applications distributed for OSX, which will make Mac users feel right 
> at home.
>
> one thing to work out is explaining how the runtime options are used. 
> this could be a point of confusion for people when they first try to 
> setup their midi/audio and add various libs to pd.

But so my interpretation of the "Mac OSX way" is slightly different. I 
see it as a real UNIX, but with all the tricky bits hidden out of 
sight. Users interact with the nice smiley bits exposed for them, but 
don't worry about the stuff hidden out of sight. Power users can use 
the command line all they like.

So that's where I was coming from with a standard /usr/local/pd folder. 
You can put a smiley "Pd start.command" in /Applications, and no one 
will be the wiser.


So yes, the externals, and in particular managing paths, are the tricky 
bit, which is where I tried to start the discussion. If we can control 
help paths in a manner similar to the lib/extern path, then we are most 
of the way there. That way, people can look at something like a 
/Library/Pd hierarchy for externals, and come up with some automagic 
way of linking help files and binaries.

( I spent an afternoon this week looking at simple heuristics for 
figuring out libraries, how help files are linked, and which .pd files 
are help files and which are not. My conclusion: the last bit is really 
hard, across the external libraries that exist. So the grand plan of a 
magic drop Folder with an attached AppleScript and shell script is on 
hold. bailing wire and glue.... )

>> Also--where do they go? The /usr/local tree (where I personally 
>> prefer to
>> put pd) is typically hidden from the user. It would be nice to be 
>> able to
>> put files in a place like /Library/Pd, where an ordinary user has the
>> capability to scre^H^H^H^Hmanipulate their installation in the finder.
>
> i think you have answered your own question.  the OSX version of pd 
> should go where the user wants it to go.  if you install to /usr/local 
> that would make pd vanish to the majority of mac users!

Well, none of the stuff in the main distribution folder is of any use 
to a normal mac user... almost nothing to view, and nothing to run from 
the finder. But a friendly pd.command in a prominent position? That 
does everything.

I also advocate a semi-standard place for the main distribution 
binaries because Pd isn't necessarily to be run directly by the user. :)

Externals are a different matter. A user probably wants to at least see 
her "plug-ins" in a user-visible folder. I'd like to accommodate that 
while putting links to help and libraries in the "right" places 
automatically.

>> We could emulate your debian approach--how does that lay out files for
>> externals (and their associated source, help, and other files)?
>
> why emulate debian at all?  it's not debian it's OSX.  if anything it 
> should more closely resemble the win32 version.

That's a point. But I was asking more about the debian packages in 
terms of how the externals are approached: is everything from an 
external kept in a single folder, with symbolic links spread 
everywhere? Are the actual binaries and helpfiles moved?

Best regards,
adam