[PD-dev] osx packages build question

[james tittle]

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

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

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

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

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

l8r,
jamie