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