[PD-dev] osx packages build question

[Hans-Christoph Steiner]

On Sep 15, 2005, at 1:29 AM, james tittle wrote:

>
> On Sep 14, 2005, at 12:33 PM, Hans-Christoph Steiner wrote:
>> A few questions:
>>
>> On Sep 1, 2005, at 8:52 PM, james tittle wrote:
>>>
>>> ...Just committed a new Makefile++ and resource file to packages  
>>> which allow building the whole shebang via gcc4.0 & using tcl/tk  
>>> 8.4.10 (or newer) :-)
>>
>> Why are you making packages?  Or do you mean a .app?  If you have a  
>> Pd.app, you don't need an installer package.  Instead of creating yet  
>> another build system for Pd, how about we try to maintain the  
>> existing one?
>
> ...um, "packages" comes from your naming of the directory that these  
> build scripts are in, but all I'm really talking about is making  
> application bundles...

Ah, ok, sorry, didn't mean to sound grumpy, I was tired.  I guess that  
wasn't the best choice of names.

>>> This really opens the door for the following releases:  devel_0_38,  
>>> devel_0_39, devel_0_39+carmen's  
>>> stuff+tcl/tk8.5+tcl/tkextensions+gridflow/ruby.framework, etc., but  
>>> also it's time to really talk about (and fix) the unified distro,
>>
>> What was wrong with the existing build system?  All of that stuff  
>> could be included in the current build system without much  
>> difficulty, AFAIK.  Its just that no one has done the work.
>
> ...well, first off it didn't work with scons (necessary for devel  
> versions), but that's an easy fix...but don't worry:  I'm not  
> re-inventing things, I've just built off of what you had done, and  
> modified it so that it worked for me on 10.4.x with gcc 4.0 and  
> such...in particular, I was also toying with a new app bundle  
> structure (tho that has been lessened since figuring out the Rez  
> trick), and using newer tcl/tk's (both 8.4.10+ and 8.5a's that I've  
> built, including extensions for "desire" and carmen's cool  
> stuff)...but also there are possible new issues with linking  
> (two_level vs. flat, using dl_open vs. NSBundle)...
>
> ...however, as it is, using the embedded wish.app makes it very  
> difficult to debug pd, since pd is then just a child process of  
> Wish...specially built versions of Wish can alleviate this, or maybe a  
> new app bundle structure...?

The problem of ditching the Wish.app structure is that you lose all of  
the nice integration work that they did, like automatic handling of  
file associations, icons, working properly on the Dock, etc.  I think a  
debug version should be possible.

>>> like what new stuff to include, how to fix up path/startup entry  
>>> preferences, whether or not we should put everything inside the .app  
>>> (thinking here about example patches that need to be opened, but  
>>> can't be because the app package is not visible in the open file  
>>> dialog)...
>>
>> I feel like this issue has been discussed a lot.  There are two ways  
>> of dealing with the problem you mention.  The Help Menu (for OSX  
>> only) and a dynamically generated symlink.
>
> ...well, I guess I just didn't pay attention to the previous  
> discussion as much...I like the help menu, but it's unfinished and  
> clunky, and even tho I'd like to fix it, I just haven't had the time  
> yet...dynamically generated symlinks may work, but don't relieve the  
> necessity of opening the app package and navigating to a particular  
> directory if you want to hand someone a  copy of a patch...of course,  
> if you can open it, you could always save it to a point outside the  
> bundle...

We can easily have both on the menu.  The symlink/file browser thing  
which would be the same as the other platforms, then the help menu for  
OSX only, unless its easy to fix for the other platforms.

> ...I'm all for docs, help patches, and abstractions inside, but I'm  
> not so much for examples...

I think we should start a separate distro of pd  
'applications'/performance patches/etc which would also be examples.   
Then all the rest would be inside the .app.

>>> ...I'm also curious as to how up-to-date the "build" directory files  
>>> are?  Fr'instance, I know zexy's been updated & split up into parts  
>>> recently, as has the iem stuff...
>>
>> Its relatively up-to-date, but I am not going to hound people to  
>> maintain their code anymore.  Feel free to do so.  Besides IOhannes,  
>> the IEM don't seem to like to work with the CVS build system, among  
>> other things.
>
> ...yeh, in the, oh, two weeks since I wrote this I figured out that  
> the build system just #includes whatever files from the externals cvs  
> repository, so it seems up-to-date...of course, without an active  
> maintainer, it's hard to know if anything's been added to certain libs  
> (fr'instance, zexy 2.1)...I don't know if it's the best way to do  
> things, but it seems to work so far...

Ones the externals/build/src/*.c shell files are in place, they'll  
automatically be up to date unless someone adds new objects or changes  
their personal build system.

.hc

________________________________________________________________________ 
____

"I have the audacity to believe that peoples everywhere can have three  
meals a day for their bodies, education and culture for their minds,  
and dignity, equality and freedom for their spirits."
                                                                          
                   - Martin Luther King, Jr.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2353 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050915/b4e684ae/attachment.bin>