Sorry to multi-thread, but I can't find the original in my pd inbox...
A few days ago, there was this thread:
"Re: [PD] Pd packaging on osx was: Re: [PD-announce] [osx] pd++0.39-1Beta available"
And Frank suggested we might want to go the Fink route for PD packages (for externals or all).
I think that's a great idea! Did anyone else agree? Is anyone moving ahead with that?
d
-- # David Plans Casal
problem.each { |day| assert_nil(spoon) }
i like this idea too. what about darwinports? btw. both of this
package management systems do have a mechanism to place .app packages
into /Applications. this option might be of interest too. i don't
know the internals neither of .deb nor of ports and i don't have time
to dive into it now - just started with my studies.
for packaging an extended/++ self containing pd version this approach
might be of interest too. just think about this possible scenario:
- install pd + externals via package management (fink/darwinports)
- run a script which grasps all the abstractions and .pd_darwins +
docs.
3. run a script which grasps all the needed dylib's from the
distribution (using "otool -L")
4. put the stuff into the right place into Pd.app
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.
@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 :)
my 2c
lorenz
Am 09.11.2005 um 10:32 schrieb David Plans Casal:
Sorry to multi-thread, but I can't find the original in my pd inbox...
A few days ago, there was this thread:
"Re: [PD] Pd packaging on osx was: Re: [PD-announce] [osx] pd++0.39-1Beta available"
And Frank suggested we might want to go the Fink route for PD
packages (for externals or all).I think that's a great idea! Did anyone else agree? Is anyone
moving ahead with that?d
-- # David Plans Casal
problem.each { |day| assert_nil(spoon) }
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On 9 Nov 2005, at 10:59, Lorenz Schori wrote:
i like this idea too. what about darwinports? btw. both of this package management systems do have a mechanism to place .app packages into /Applications. this option might be of interest too. i don't know the internals neither of .deb nor of ports and i don't have time to dive into it now - just started with my studies. for packaging an extended/++ self containing pd version this approach might be of interest too.
I'm going to go through the fink packaging tutorial. I have slightly more faith in it than darwinports, so I'll start there. If anyone else is looking at the same time, please shout!
just think about this possible scenario:
- install pd + externals via package management (fink/darwinports)
+1
- 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 was just thinking of one big Pd.app being dumped in /Applications, with all needed externals pre-built.
- run a script which grasps all the needed dylib's from the
distribution (using "otool -L")
Interesting.
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.
@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?
Anyway, I think it's a good idea overall!
d
-- # David Plans Casal
problem.each { |day| assert_nil(spoon) }
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
- 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.
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.
- 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.html
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.
Anyway, I think it's a good idea overall!
d
-- # David Plans Casal
problem.each { |day| assert_nil(spoon) }
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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.html
otool 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
Hallo, james tittle hat gesagt: // james tittle wrote:
...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?
But that's exactly the selling point of the fink approach: Someone else would do this!!
In a perfect world, Fink has packages for libquicktime, libtheora, ffmpeg, libfluidsynth etc. and what a Pd fink package would do, is build Pd and externals using the upstream libraries as available in fink.
The package management is intelligent enough to figure out the right version of a library to install, to make Pd, Gem, PDP etc. run correctly.
This is already working on most Linux systems like Debian, which was the model for fink. Guenther, who maintains the Pd package, is not maintaining the fluidsynth package, he's just using it to build the [fluid~] external.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
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".
2. 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.
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.
keep up the work but please be a bit open for new ideas and try to
understand them...
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.html
otool 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
Hallo, Lorenz Schori hat gesagt: // Lorenz Schori wrote:
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.
Just to add a bit here: Packaging for Fink (I suppose, if it's similar to Debian) will be an additional operation that sits on top of whatever build system we use to actually build Pd and externals. Using Guenther's Debian packages as example again: The Debian packaging tools just use the externals/build/ system to build everything. For Pd they use ./configure && make and for flext-externals they use flext-build.
So there's no real need change anything in the system to compile stuff in the context of how to package stuff.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Wed, 9 Nov 2005, Frank Barknecht wrote:
Just to add a bit here: Packaging for Fink (I suppose, if it's similar to Debian) will be an additional operation that sits on top of whatever build system we use to actually build Pd and externals. Using Guenther's Debian packages as example again: The Debian packaging tools just use the externals/build/ system to build everything. For Pd they use ./configure && make and for flext-externals they use flext-build.
.. I thought I have to comment on this too, as I think that my Debian packages, or at least the part that is mentioned here should not be taken as a good example. I have to admit that I couldn't find a way how to build and package the huge amount of externals that is available in a way that is maintainable.
Currently I am only packaging pd itself, gem, zexy and pdp, there is also a package for flext around, but I just do not find the time to update it accordingly (so its a almost 0.5.0 CVS snapshot).
The initial idea of the CVS was to organize all of this a bit, but what happened is that although most developers are willing to put their code there, we generated the problem of how to manage this amount of code. I don't know how :( Maybe we just have to accept that building the externals is and will stay a challenge.
Cheers,
Guenter
So there's no real need change anything in the system to compile stuff in the context of how to package stuff.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
...sigh...
On Nov 9, 2005, at 12:00 PM, Lorenz Schori wrote:
- [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.
...I don't think you've really understood or read the makefile in
darwin_app? There already ARE ways to "throw" these things out:
looking down the list, I see breakups such as "darwin_app_wrapper",
"darwin_app_core", "darwin_app_docs",
"darwin_app_externals_standard", "darwin_app_externals_flext",
etc...I wonder what they're for? Hmm, maybe if I search for those
terms, then I find that they are weirdly bunched on lines that start
with "darwin_app_externals" and "darwin_app"...oh drat, it's all too
much to think about, let's do something else...
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.
...me too...
keep up the work but please be a bit open for new ideas and try to
understand them...
...I'm always listening...
james
-----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
Hey
As always in the FLOSS world, by the time you start work on something, someone smarter has already done it :-)
On 9 Nov 2005, at 23:12, Hans-Christoph Steiner wrote:
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.
Could you explain what you mean by 'sponsored'? If you mean you're getting funded to actively work on PD's build system, this is wonderful news!
I agree with Frank that the point of Fink is upstream libs and separation of concerns, which is why I spent hours yesterday looking at packaging pd in fink; the result of which is...I can see Hans's point:
If we can use the darwin_app/Makefile to produce a Fink package (or darwinports, or gentoo, or whatever, especially .deb), then the package 'maintainer' job disappears, since all that has to happen is, we keep different packages generated from that makefile in puredata.info, for people to get, or they get submitted to fink tracker, or whatever.
In any case, generating packages from a unified build system makes sense. No?
If you look at just your particular OS/package preference, you don't see the whole picture.
Point taken.
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.
I think I would really appreciate the ability to rely on fink packages so that if I need a lib I'm thinking through fink, not a hand-compiled mess. And, I'd like to help achieve that. However, I'm not going to get in the way of a sensible idea, like unifying builds and generating packages from that.
How does Hans' work relate to James'? Is James just packaging .app s outside the remit of Hans' darwin_app?
Maybe we could coalesce efforts at this point?
d
-- # David Plans Casal
problem.each { |day| assert_nil(spoon) }
On Nov 10, 2005, at 5:45 AM, David Plans Casal wrote:
Hey
As always in the FLOSS world, by the time you start work on something,
someone smarter has already done it :-)On 9 Nov 2005, at 23:12, Hans-Christoph Steiner wrote:
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.Could you explain what you mean by 'sponsored'? If you mean you're
getting funded to actively work on PD's build system, this is
wonderful news!
Yes, there are currently two sponsors:
Anders Friberg organized sponsorship for a common Windows build, here's
the official sponsor: "The development was sponsored by the Music
acoustics group, KTH, Stockholm (http://www.speech.kth.se/music/) and
the S2S^2 European coordinating action (http://www.s2s2.org)"
And Martin Dupras organized sponsorship of a cross-platform build
system from his university, University of West England.
Thanks much to both of them, they really deserve the praise since they
stepped up and offered and then did the bureaucratic legwork.
Hopefully, this can serve as a model future funding of Pd development.
This just put my lifetime free software earnings above US$2000. Its a
start...
I agree with Frank that the point of Fink is upstream libs and
separation of concerns, which is why I spent hours yesterday looking
at packaging pd in fink; the result of which is...I can see Hans's
point:If we can use the darwin_app/Makefile to produce a Fink package (or
darwinports, or gentoo, or whatever, especially .deb), then the
package 'maintainer' job disappears, since all that has to happen is,
we keep different packages generated from that makefile in
puredata.info, for people to get, or they get submitted to fink
tracker, or whatever.In any case, generating packages from a unified build system makes
sense. No?
Yes indeed, that is the grand plan, I hope to get the foundation
implemented by the end of the month, along with Windows, OSX, and Linux
binaries all from the same source. The further packaging (deb, rpm,
fink, darwinports, etc.) will be up to who ever wants to do it.
If you look at just your particular OS/package preference, you don't
see the whole picture.Point taken.
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.I think I would really appreciate the ability to rely on fink packages
so that if I need a lib I'm thinking through fink, not a hand-compiled
mess. And, I'd like to help achieve that. However, I'm not going to
get in the way of a sensible idea, like unifying builds and generating
packages from that.How does Hans' work relate to James'? Is James just packaging .app s
outside the remit of Hans' darwin_app?
Jamie is basically doing a minor development fork of
package/darwin_app/Makefile. I'll be incorporating basically all of
his changes now that he's got it all ironed out.
Maybe we could coalesce efforts at this point?
Sounds like a great idea. You could start by looking at
packages/darwin_app/Makefile, and take it from there. But beware,
there will be substantial changes as I make it platform-neutral.
.hc
d
-- # David Plans Casal
problem.each { |day| assert_nil(spoon) }
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
¡El pueblo unido jamás será vencido!
On 10 Nov 2005, at 21:30, Hans-Christoph Steiner wrote:
Thanks much to both of them, they really deserve the praise since they stepped up and offered and then did the bureaucratic legwork.
Hopefully, this can serve as a model future funding of Pd development. This just put my lifetime free software earnings above US$2000. Its a start...
Heh. Well, I'm currently trying to raise funds for gridflow (docs, etc.) and trying to find general puredata funding too. I know how hard it can be, so kudos to them guys.
Yes indeed, that is the grand plan, I hope to get the foundation implemented by the end of the month, along with Windows, OSX, and Linux binaries all from the same source. The further packaging (deb, rpm, fink, darwinports, etc.) will be up to who ever wants to do it.
THat's fantastic news.
Sounds like a great idea. You could start by looking at packages/darwin_app/Makefile, and take it from there. But beware, there will be substantial changes as I make it platform-neutral.
But this is in CVS, so regularly watching cvs digest and doing cvs updates should keep me sane, right?
d
-- # David Plans Casal
problem.each { |day| assert_nil(spoon) }
On Nov 11, 2005, at 4:50 AM, David Plans Casal wrote:
On 10 Nov 2005, at 21:30, Hans-Christoph Steiner wrote:
Thanks much to both of them, they really deserve the praise since
they stepped up and offered and then did the bureaucratic legwork.
Hopefully, this can serve as a model future funding of Pd
development. This just put my lifetime free software earnings above
US$2000. Its a start...Heh. Well, I'm currently trying to raise funds for gridflow (docs,
etc.) and trying to find general puredata funding too. I know how hard
it can be, so kudos to them guys.
Good luck with it.
Yes indeed, that is the grand plan, I hope to get the foundation
implemented by the end of the month, along with Windows, OSX, and
Linux binaries all from the same source. The further packaging (deb,
rpm, fink, darwinports, etc.) will be up to who ever wants to do it.THat's fantastic news.
Sounds like a great idea. You could start by looking at
packages/darwin_app/Makefile, and take it from there. But beware,
there will be substantial changes as I make it platform-neutral.But this is in CVS, so regularly watching cvs digest and doing cvs
updates should keep me sane, right?
Yes, all of this is/will be in CVS. I've already made a few related
commits.
.hc
d
-- # David Plans Casal
problem.each { |day| assert_nil(spoon) }
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"Information wants to be free." -Stewart Brand
*snip*
And Frank suggested we might want to go the Fink route for PD packages (for externals or all).
Not everybody uses Fink though - and to force people to use Fink as an "easy route" to install Pure Data isn't something I am comfortable with.
Offering PD via Fink however would be nice as an alternative, but I for one would definitely like to see .dmg or the like be the main method for OS X distribution.
-
David Plans Casal -
Frank Barknecht -
günter geiger -
Hans-Christoph Steiner -
james tittle -
Lorenz Schori -
nacht