-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Nov 9, 2005, at 12:00 PM, Lorenz Schori wrote:
so let's not mix things together.
- frank and then david thought about packing pd into fink. i would
like to see it in darwinports. for dependency tracking, installing
externals which rely on shared libraries (i prefer them over static
linked ones) one of those package systems just _is_ better. i stated
in my first answer to david: "i'm just thinking about how pd on mac
could be more conveniant for (doubleclick)users AND (cli)developers".
I am a big fan of Fink and use it quite a bit. I just don't think that
its the best way to distribute Pd on Mac OS X. On reason is that I
think we need to start thinking of all this code not as externals and
plugins, but a platform like Java. When you download Java, you don't
download the language and the "externals" separately, even though it is
a vast collection of objects written by many different people.
Without much effort, the Pd.app could be made much more friendly to CLI
people. Certainly it would take less time that creating fink or
darwinports packages. Its been on my TODO list for a long time, it
just hasn't been a high priority. On the most basic level, a Tcl
script could be written which maintains symlinks in the standard UNIX
locations (/usr/local/lib, ../bin, ../include etc.). These symlinks
would then point to the contents inside the Pd.app. There would be a
menu option to run this script, or you could just run it from the
command line. Then you could have a Pd.app that is drag-n-drop
installable, runnable from any location, and works for the CLI people.
- i did read man otool, man install_name_tool, man dyld, man ld and
many others, i know much about shared/static libraries, bundles and
frameworks and i did investigations on the web and in the list
regarding a cleaner and more flexible way to build and maintain
pd.app. i know the problems with packing pd and tracking dependancies
and i know the buildsystems and... 3. [rant here] i don't like the darwin_app makefiles. i suggest you to
break things down into logical units, e.g. throw out the html docs, do
externals seperate, just concentrate on the objective (building the
pd.app). so poeple looking at it will find what they need. [end of
rant]. i don't want to discuss this further because i don't have the
time to work on a better system.
Things are mostly already broken down into logical units. Pd,
externals, flext, those all have distinct build systems which are just
called from packages/darwin_app/Makefile. I have now been sponsored to
make this build system cross-platform, and cross-packaging system even.
So after this is done, it will be easier to make fink packages,
darwinports, RPMs, DEBs, gentoo packages, etc. All with the huge
benefit of having the exact same contents in every package across all
platforms.
If you look at just your particular OS/package preference, you don't
see the whole picture.
don't get me wrong. i like yours and hans work but i'm just a bit
annoyed that i have to mess around with too much build related
problems if i want to change just little things in pd.
Its a big ugly tangle of code, differing coding styles, a myriad of
build systems. No matter how you package it or build it, its not going
to be easy.
keep up the work but please be a bit open for new ideas and try to
understand them...
Packaging Pd in Fink and/or Darwinports are not new ideas, they are old
ones. We chose to go the Pd.app route because it provides the most
flexibility and behaves the most like a native app, which is what
almost all Mac OS X users want, this CLI guy included.
As I have said before, I am not going to stop anyone, but all I ask is
that we spend our limited resources on other things besides reinventing
the build system wheel. Fink or Darwinports packages could be useful,
so please at the very least, let's work together to have one system
that can work for building.
.hc
lorenz
Am 09.11.2005 um 17:34 schrieb james tittle:
On Nov 9, 2005, at 6:28 AM, Lorenz Schori wrote:
Am 09.11.2005 um 12:15 schrieb David Plans Casal:
just think about this possible scenario:
- install pd + externals via package management (fink/darwinports)
+1
...it wouldn't be hard to add a pd package to fink or darwinports,
but I don't think there's that much demand since there's already
several app bundles available...plus, who's got the time to make
packages for the dependencies of all the externals?
- run a script which grasps all the abstractions and .pd_darwins
- docs.
From where? I mean once you've installed with 'fink install pd' or
whatever, how do you envision running the script?i imagine something like pdadmin or phps pdmkapp you mentioned below.
...have ya'll not heard of the "package" build system in cvs? It
does exactly this, for an app bundle...I was just thinking of one big Pd.app being dumped in
/Applications, with all needed externals pre-built.cool. this will be step 1.
...again, this has been done: I can think of at least three
available: mine (pd++.app), Hans', and ben's pixeltango...why
re-invent the wheel?
- run a script which grasps all the needed dylib's from the
distribution (using "otool -L")
Interesting.
but sadly not quite straight forward. see
http://qin.laya.com/tech_coding_help/dylib_linking.htmlotool won't help much here beyond telling you what is being linked
against: your friend is "install_name_tool", ask man for info...this mechanism could be extended to provide a way to easily deploy
custom Pd.app which just include needed externals and possibly
have patches autostarted.Ok so we could have CLI instructions such as:
'pdadmin myinstallation'
And output would be a myinstallation.app/ directory with pd
binaries, externals, etc? I guess CLI options to that would be
nice. A bit like Django and Rails options.Not sure though, how one would go about building this.
me neither. just ideas.
@hans+james. this is no rant against you and i don't want to just
create another build system. i'm just thinking about how pd on mac
could be more conveniant for (doubleclick)users AND
(cli)developers :)And yes, why not rely on the current build systems?
don't know how they will go with fink.
...I use fink for the dependency libs right now...again, I understand
and encourage your interest, but spend some time looking thru the
archives here, and you'll see that this has been well covered over
the last few years...l8r, james
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"Computer science is no more related to the computer than astronomy is
related to the telescope."
-Edsger
Dykstra