Hallo,
over to pd-dev...
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Dec 26, 2005, at 1:32 PM, Frank Barknecht wrote:
I'm currently trying to adapt the debian build files in CVS to use Hans' global makefile, a lot of help comes from Martin Rumori in this task. In fact he did most of the work so far. We managed to build installed packages which basically follow Hans' makefile and do everything, his make system does. However I don't want to put any work into pd-0.38 anymore, so these are for pd-0.39 (or CVS head) and don't include the libdir or comment patches by Hans. They haven't been published yet, it's still christmas time here. Probably this will take till 2006 anyway.
Why not include the libdir patch? It applies fine with 0.39 and its a safe change, its not major surgery. Which is the comment patch?
I don't know, where it is, but you support international characters in pd-extended, right? That's what I'm refering to.
So far building Debian packages out of Hans' stuff looks very promising. A problem still is, that Hans' main makefile isn't yet ready to be used only partially. That is, "make all" works fine, but "make only_part_of_all" often doesn't.
Please report problems so they can be fixed. Which is the main Makefile, packages/Makefile? Which parts aren't working? I know that the clean targets could use some work...
As packaging pd itself is no major problem (in fact, since xmas there is a pd-0.39-2 package in testing) I just want to build externals for now.
So I do this: $ make externals prefix=/usr DESTDIR=/home/fbar/tmp/pd-pack
It bails out with this:
cd /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../externals && make BUILDLAYOUT_DIR=/home/fbar/pd/packages/packages-neu/packages/pure-data/packages cvs_root_dir=/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/.. DESTDIR=/home/fbar/tmp/pd-pack prefix=/usr libpddir=/home/fbar/tmp/pd-pack/usr/lib/pd OPT_CFLAGS="" UNAME=Linux make[1]: Entering directory `/home/fbar/pd/packages/packages-neu/packages/pure-data/externals' cc -DPD -I/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../pd/src -Wall -W -Wno-unused -Wno-parentheses -Wno-switch -Wno-shadow -DUNIX -Dunix -fPIC -o "/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../externals/build/src/ENV.o" -c "/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../externals/build/src/ENV.c" cc -Wl,-export_dynamic -shared -o "/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../externals/build/src/ENV.pd_linux" /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../externals/hcs/hid/input_arrays.o /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../externals/hcs/hid/hid_linux.o /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../externals/hcs/hid/hid.o -lm -lc cc: /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../externals/hcs/hid/input_arrays.o: No such file or directory cc: /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../externals/hcs/hid/hid_linux.o: No such file or directory cc: /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../externals/hcs/hid/hid.o: No such file or directory make[1]: *** [/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../externals/build/src/ENV.pd_linux] Error 1 rm /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../externals/build/src/ENV.o make[1]: Leaving directory `/home/fbar/pd/packages/packages-neu/packages/pure-data/externals' make: *** [externals] Error 2
And actually I want to build externals without Gem, as Gem also has nice Pd packages and may be easier built from its own CVS. I would at least vote for making Gem, PDP/Pidip and Gridflow their own targets inside the makefile, like "make gem(_install) gridflow(_install) pdp(_install)"
Then Pd is not configured to use the prefix given in the make command:
$ make pd prefix=/usr DESTDIR=/home/fbar/tmp/pd-pack cd /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../pd/src/ && autoconf echo $MACOSX_DEPLOYMENT_TARGET
cd /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../pd/src && ./configure --enable-jack && \ make BUILDLAYOUT_DIR=/home/fbar/pd/packages/packages-neu/packages/pure-data/packages cvs_root_dir=/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/.. DESTDIR=/home/fbar/tmp/pd-pack prefix=/usr libpddir=/home/fbar/tmp/pd-pack/usr/lib/pd OPT_CFLAGS="" UNAME=Linux
I think, this should be " ./configure --enable-jack prefix=$prefix" or similar.
Ciao
On Dec 27, 2005, at 1:57 AM, Frank Barknecht wrote:
Hallo,
over to pd-dev...
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Dec 26, 2005, at 1:32 PM, Frank Barknecht wrote:
I'm currently trying to adapt the debian build files in CVS to use Hans' global makefile, a lot of help comes from Martin Rumori in this task. In fact he did most of the work so far. We managed to build installed packages which basically follow Hans' makefile and do everything, his make system does. However I don't want to put any work into pd-0.38 anymore, so these are for pd-0.39 (or CVS head) and don't include the libdir or comment patches by Hans. They haven't been published yet, it's still christmas time here. Probably this will take till 2006 anyway.
Why not include the libdir patch? It applies fine with 0.39 and its a safe change, its not major surgery. Which is the comment patch?
I don't know, where it is, but you support international characters in pd-extended, right? That's what I'm refering to.
Ah, ok, I thought I documented this somewhere, but maybe I forgot to. In packages/patches, all the patches used for Pd-extended are checked into CVS. You can apply/unapply them by:
cd packages && make patch_pd cd packages && make unpatch_pd
The int'l char patch is super simple, and it seems to work ok, so I think it'd be good to include. Part of my goal with the Pd-extended build system was to have a system of managing patches so that we can have a testing ground before submitting them to Miller, etc. Also, it allows us to distribute smaller changes to Pd core without the major surgery of pd-devel.
So far building Debian packages out of Hans' stuff looks very promising. A problem still is, that Hans' main makefile isn't yet ready to be used only partially. That is, "make all" works fine, but "make only_part_of_all" often doesn't.
Please report problems so they can be fixed. Which is the main Makefile, packages/Makefile? Which parts aren't working? I know that the clean targets could use some work...
As packaging pd itself is no major problem (in fact, since xmas there is a pd-0.39-2 package in testing) I just want to build externals for now.
So I do this: $ make externals prefix=/usr DESTDIR=/home/fbar/tmp/pd-pack
FYI, you can also do this, they are the same thing: cd externals && make install prefix=/usr DESTDIR=/home/fbar/tmp/pd-pack
It bails out with this:
cd /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ externals && make BUILDLAYOUT_DIR=/home/fbar/pd/packages/packages-neu/packages/pure- data/packages cvs_root_dir=/home/fbar/pd/packages/packages-neu/packages/pure-data/ packages/.. DESTDIR=/home/fbar/tmp/pd-pack prefix=/usr libpddir=/home/fbar/tmp/pd-pack/usr/lib/pd OPT_CFLAGS="" UNAME=Linux make[1]: Entering directory `/home/fbar/pd/packages/packages-neu/packages/pure-data/externals' cc -DPD -I/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ pd/src -Wall -W -Wno-unused -Wno-parentheses -Wno-switch -Wno-shadow -DUNIX -Dunix -fPIC -o "/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ externals/build/src/ENV.o" -c "/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ externals/build/src/ENV.c" cc -Wl,-export_dynamic -shared -o "/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ externals/build/src/ENV.pd_linux" /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ externals/hcs/hid/input_arrays.o /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ externals/hcs/hid/hid_linux.o /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ externals/hcs/hid/hid.o -lm -lc cc: /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ externals/hcs/hid/input_arrays.o: No such file or directory cc: /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ externals/hcs/hid/hid_linux.o: No such file or directory cc: /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ externals/hcs/hid/hid.o: No such file or directory make[1]: *** [/home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ externals/build/src/ENV.pd_linux] Error 1 rm /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../ externals/build/src/ENV.o make[1]: Leaving directory `/home/fbar/pd/packages/packages-neu/packages/pure-data/externals' make: *** [externals] Error 2
That's very strange. I can't reproduce this on Debian, Mac OS X, or Windows. Its trying to compile [hid] files into the [ENV] object. Have you don't a "cvs up -Pd" on "externals" and "packages"? Are there any files in your "externals/build/src" which are not from CVS?
And actually I want to build externals without Gem, as Gem also has nice Pd packages and may be easier built from its own CVS. I would at least vote for making Gem, PDP/Pidip and Gridflow their own targets inside the makefile, like "make gem(_install) gridflow(_install) pdp(_install)"
cd externals && make pdp_install cd externals && make pidip_install
I know nothing about building GridFlow, and Gem can be compiled by: cd packages && make gem_install
Personally, I think that the Debian packages should reflect the other Pd-extended builds and just be one package. I could see separating out the Pd core, so that you could use different versions with the same pd-extended externals, docs, etc. but that might cause problems since some externals might only work properly with the version of Pd that they were compiled against.
I just don't see any advantage to having all of this stuff separated into separate packages. For example, Gem is useless without Pd, and if its not being used it does no harm, it just takes up disk space.
The one small advantage I could see is having a package that would have objects without dependencies, but that could be a lot of work to create. Even some of the objects in externals/build/src have some dependencies (though that could be easily changed).
Then Pd is not configured to use the prefix given in the make command:
$ make pd prefix=/usr DESTDIR=/home/fbar/tmp/pd-pack cd /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../pd/ src/ && autoconf echo $MACOSX_DEPLOYMENT_TARGET
cd /home/fbar/pd/packages/packages-neu/packages/pure-data/packages/../pd/ src && ./configure --enable-jack && \ make BUILDLAYOUT_DIR=/home/fbar/pd/packages/packages-neu/packages/pure- data/packages cvs_root_dir=/home/fbar/pd/packages/packages-neu/packages/pure-data/ packages/.. DESTDIR=/home/fbar/tmp/pd-pack prefix=/usr libpddir=/home/fbar/tmp/pd-pack/usr/lib/pd OPT_CFLAGS="" UNAME=Linux
I think, this should be " ./configure --enable-jack prefix=$prefix" or similar.
If Pd had a proper autotools build system, then it would be:
./configure --enable-jack --with-prefix=$prefix
But it does not, it has a kind of hacked up version. The current setup barely uses ./configure, for example. Therefore, its much easier to just override the Makefile variable using:
make prefix=$prefix
.hc
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Dec 27, 2005, at 1:57 AM, Frank Barknecht wrote:
So I do this: $ make externals prefix=/usr DESTDIR=/home/fbar/tmp/pd-pack
...
It bails out with this:
cd
...
That's very strange. I can't reproduce this on Debian, Mac OS X, or Windows. Its trying to compile [hid] files into the [ENV] object. Have you don't a "cvs up -Pd" on "externals" and "packages"? Are there any files in your "externals/build/src" which are not from CVS?
I am doing all this with superfresh checkouts actually, using the developer-checkout script from "scripts".
And actually I want to build externals without Gem, as Gem also has nice Pd packages and may be easier built from its own CVS. I would at least vote for making Gem, PDP/Pidip and Gridflow their own targets inside the makefile, like "make gem(_install) gridflow(_install) pdp(_install)"
cd externals && make pdp_install cd externals && make pidip_install
Okay, this looks like a good idea.
I know nothing about building GridFlow, and Gem can be compiled by: cd packages && make gem_install
Or not compiled. ;)
Personally, I think that the Debian packages should reflect the other Pd-extended builds and just be one package. I could see separating out the Pd core, so that you could use different versions with the same pd-extended externals, docs, etc. but that might cause problems since some externals might only work properly with the version of Pd that they were compiled against.
I just don't see any advantage to having all of this stuff separated into separate packages. For example, Gem is useless without Pd, and if its not being used it does no harm, it just takes up disk space.
It takes up much more because of all the dependencies it has. And dependencies are not only something which takes up disk space, they are something which can and will break on upgrades.
If someone is not interested in the video side of Pd at all or if someone wants to run Pd on an X-less webserver, then there would be no need to install Gem and all its dependencies. Without Gem and pdp, an externals package's dependencies would be supersmall, but including Gem and pdp you need a really huge list of packages to install for two externals, that are totally useless to maybe half of Pd's usersbase (just a guess for the sake of the argument).
And I'm not even mentioning build-dependencies yet, which should also be taken into account at least on Debian and probably Gentoo.
That's why I would prefer that Gem and pdp go into their own packages (and that pd-extended reflects the Debian builds and just be several packages ;) and users can make their own choice. (And they chose Firefox and Thunderbird over Mozilla.)
Ciao
On Dec 27, 2005, at 11:20 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Dec 27, 2005, at 1:57 AM, Frank Barknecht wrote:
So I do this: $ make externals prefix=/usr DESTDIR=/home/fbar/tmp/pd-pack
...
It bails out with this:
cd
...
That's very strange. I can't reproduce this on Debian, Mac OS X, or Windows. Its trying to compile [hid] files into the [ENV] object. Have you don't a "cvs up -Pd" on "externals" and "packages"? Are there any files in your "externals/build/src" which are not from CVS?
I am doing all this with superfresh checkouts actually, using the developer-checkout script from "scripts".
I found the problem and fixed it. It was my fault, sorry about that. I am going crazy keeping track of files on three different computers (Mac OS X, Debian, and Windows). "cvs up externals/Makefile" and please try again.
And actually I want to build externals without Gem, as Gem also has nice Pd packages and may be easier built from its own CVS. I would at least vote for making Gem, PDP/Pidip and Gridflow their own targets inside the makefile, like "make gem(_install) gridflow(_install) pdp(_install)"
cd externals && make pdp_install cd externals && make pidip_install
Okay, this looks like a good idea.
I know nothing about building GridFlow, and Gem can be compiled by: cd packages && make gem_install
Or not compiled. ;)
Oops, sorry, I forgot its not included yet since I haven't worked on the autotools building of Gem yet.
Personally, I think that the Debian packages should reflect the other Pd-extended builds and just be one package. I could see separating out the Pd core, so that you could use different versions with the same pd-extended externals, docs, etc. but that might cause problems since some externals might only work properly with the version of Pd that they were compiled against.
I just don't see any advantage to having all of this stuff separated into separate packages. For example, Gem is useless without Pd, and if its not being used it does no harm, it just takes up disk space.
It takes up much more because of all the dependencies it has. And dependencies are not only something which takes up disk space, they are something which can and will break on upgrades.
If someone is not interested in the video side of Pd at all or if someone wants to run Pd on an X-less webserver, then there would be no need to install Gem and all its dependencies. Without Gem and pdp, an externals package's dependencies would be supersmall, but including Gem and pdp you need a really huge list of packages to install for two externals, that are totally useless to maybe half of Pd's usersbase (just a guess for the sake of the argument).
And I'm not even mentioning build-dependencies yet, which should also be taken into account at least on Debian and probably Gentoo.
That's why I would prefer that Gem and pdp go into their own packages (and that pd-extended reflects the Debian builds and just be several packages ;) and users can make their own choice. (And they chose Firefox and Thunderbird over Mozilla.)
The dependencies argument is a valid one, but that will be a lot of work to setup and maintain, it seems to me. Are you then going to have to make pd-ogg, pd-mp3, pd-speex, pd-libsndfile, etc?
Audacity is a good example, its a similar program. The audacity package has a long list of deps on top of the minimum: libflac++5, libflac7, libid3tag, libmad0, libogg0, libsndfile1, libunwind7, libvorbis0a, libvorbisen2, libvorbisfile3. Ardour has an even longer list: http://packages.debian.org/unstable/sound/ardour-gtk, and ffmpeg has a decent list too: http://packages.debian.org/unstable/graphics/ffmpeg
I think that Pd is much closer to Ardour/Audacity/ffmpeg than Mozilla, especially when you consider that Firefox and Thunderbird are standalone apps, while none of the Pd sub-packages will do anything without Pd.
But I am probably not going to do the work, so its just my opinion.
.hc
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
hello,
just my two cents, not haveing read all the threads...
Personally, I think that the Debian packages should reflect the other Pd-extended builds and just be one package. I could see separating out the Pd core, so that you could use different versions with the same pd-extended externals, docs, etc. but that might cause problems since some externals might only work properly with the version of Pd that they were compiled against.
I just don't see any advantage to having all of this stuff separated into separate packages. For example, Gem is useless without Pd, and if its not being used it does no harm, it just takes up disk space.
It takes up much more because of all the dependencies it has. And dependencies are not only something which takes up disk space, they are something which can and will break on upgrades.
If someone is not interested in the video side of Pd at all or if someone wants to run Pd on an X-less webserver, then there would be no need to install Gem and all its dependencies. Without Gem and pdp, an externals package's dependencies would be supersmall, but including Gem and pdp you need a really huge list of packages to install for two externals, that are totally useless to maybe half of Pd's usersbase (just a guess for the sake of the argument).
And I'm not even mentioning build-dependencies yet, which should also be taken into account at least on Debian and probably Gentoo.
That's why I would prefer that Gem and pdp go into their own packages (and that pd-extended reflects the Debian builds and just be several packages ;) and users can make their own choice. (And they chose Firefox and Thunderbird over Mozilla.)
The dependencies argument is a valid one, but that will be a lot of work to setup and maintain, it seems to me. Are you then going to have to make pd-ogg, pd-mp3, pd-speex, pd-libsndfile, etc?
Audacity is a good example, its a similar program. The audacity package has a long list of deps on top of the minimum: libflac++5, libflac7, libid3tag, libmad0, libogg0, libsndfile1, libunwind7, libvorbis0a, libvorbisen2, libvorbisfile3. Ardour has an even longer list: http://packages.debian.org/unstable/sound/ardour-gtk, and ffmpeg has a decent list too: http://packages.debian.org/unstable/graphics/ffmpeg
I think that Pd is much closer to Ardour/Audacity/ffmpeg than Mozilla, especially when you consider that Firefox and Thunderbird are standalone apps, while none of the Pd sub-packages will do anything without Pd.
What is if I want my own GEM tree and not the debian one, because GEM has a lot of compilation option, then it would be nice just not install Gem to not get mixed with the the debian.
A good example of many debian packages is python or zope, where every product is zope-gruf, zope-squishdot, ....
other poeple can add their packages too in the same manner.
But I am probably not going to do the work, so its just my opinion.
thats a good point,
... maybe would be easier for you not to package them, since their maybe different dependencies for video libraries, which cant be used parallel... (there was such a case some time ago).
... maybe its better if there are big projects like GEM, the packages are made by themselves, maybe they make some own versions and rythm for release with different dependencies.
mfg winfried
.hc
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Winfried Ritsch hat gesagt: // Winfried Ritsch wrote:
What is if I want my own GEM tree and not the debian one, because GEM has a lot of compilation option, then it would be nice just not install Gem to not get mixed with the the debian.
That's actually, why I'm so in favour of having seperate packages in Debian (or generally). Debian packages are not only binary packages, they come as source packages, too, and using Debian's packaging tools makes it easy to build custom Debian packages of Gem locally as in:
$ fakeroot debian/rules binary $ dpkg -i ../*.deb
When doing packages for Debian, I think, the needs of people who compile their own stuff using Debian's tools should be taken into account as well. Everyone is a maintainer, the line to "pure users" is blurred or non-existant here.
Ciao
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The dependencies argument is a valid one, but that will be a lot of work to setup and maintain, it seems to me. Are you then going to have to make pd-ogg, pd-mp3, pd-speex, pd-libsndfile, etc?
I don't think it has to be such a black and white picture drawn just by technical demands. I'm actually in favour of a more use-oriented approach and I would draw the line between video/gfx and audio/midi. Pd itself is useless without basic audio or midi support. So the audio users would form the base user group. These people probably will have libsndfile or libogg installed anyways.
Additionally there are gfx-oriented externals, which require audio stuff anyway, because of their dependency on Pd, but they also require stuff like video codecs, which is of no use on a purely audio system.
I'm deliberately simplifiying here, of course, as e.g. Gridflow is much more than just a video external.
A user who wants to have everything can just install every pd-related package, which could be made even easier in Debian by providing a dummy package, e.g. pd-complete, that is empty itself, but depends on all pd-related packages.
So what I'm thinking of is just a handful of packages:
* pd * pd-externals (including flext?) * pd-gfx (Gem and pdp, maybe Gridflow) * pd-doc (additional documentation, tutorials etc.) * pd-abstractions (this could also be merged with pd-externals) * And maybe language-specific packages like pd-python, pd-ruby, pd-snd/-scheme.
(I don't want to deinstall the whole Pd, just because there's a new python version coming...)
IMO this kind of setup has advantages over the one-size-fits-all package both for users and maintainers.
Ciao
On Dec 28, 2005, at 4:18 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The dependencies argument is a valid one, but that will be a lot of work to setup and maintain, it seems to me. Are you then going to have to make pd-ogg, pd-mp3, pd-speex, pd-libsndfile, etc?
I don't think it has to be such a black and white picture drawn just by technical demands. I'm actually in favour of a more use-oriented approach and I would draw the line between video/gfx and audio/midi. Pd itself is useless without basic audio or midi support. So the audio users would form the base user group. These people probably will have libsndfile or libogg installed anyways.
Additionally there are gfx-oriented externals, which require audio stuff anyway, because of their dependency on Pd, but they also require stuff like video codecs, which is of no use on a purely audio system.
I'm deliberately simplifiying here, of course, as e.g. Gridflow is much more than just a video external.
A user who wants to have everything can just install every pd-related package, which could be made even easier in Debian by providing a dummy package, e.g. pd-complete, that is empty itself, but depends on all pd-related packages.
So what I'm thinking of is just a handful of packages:
- pd
- pd-externals (including flext?)
- pd-gfx (Gem and pdp, maybe Gridflow)
- pd-doc (additional documentation, tutorials etc.)
- pd-abstractions (this could also be merged with pd-externals)
- And maybe language-specific packages like pd-python, pd-ruby,
pd-snd/-scheme.
(I don't want to deinstall the whole Pd, just because there's a new python version coming...)
IMO this kind of setup has advantages over the one-size-fits-all
package both for users and maintainers.
Ok, I think I am convinced about the separate packages argument, since Pd is more of a programming language than an app. But I think going back to the dependency argument, there should be a package of externals with only the very minimal dependencies (i.e. libc6, pd). There are more and more people who only use Pd for video work, so I think the audio and video stuff should be treated the same
So here's my proposal for the layout:
pd (provided by puredata, desiredata, pd-devel, etc.) pd-doc (this may be unclear, its more like built-in help than standalone docs) pd-externals ("abstractions" and "externals" with no deps) pd-audio (anything needing extra sound libs) pd-video (virtual package for all video packages). pd-gem pd-pdp pd-pidip pd-gridflow pd-pdp
pd-gem, pd-pdp, and pd-pidip already exist in some form, and having them separate would facillitate source building. But its probably better to organize the packages in the most Debian way possible, rather than the Pd way since people who want to do things the Pd way can build directly from source. I love Debian because everything is done the Debian way and makes my life much easier.
To fascillate this, it would probably make sense to add some special debian targets to "externals/Makefile". Something like:
-------------- DEBIAN_EXTERNALS_TARGETS = buildsrc creb cxc cyclone ext13 freeverb hid iemabs iemlib iemmatrix loaders markex maxlib mjlib motex oscx pddp pmpd smlib toxy vbap zexy debian_externals: DEBIAN_AUDIO_TARGETS = pdogg unauthorized
debian_externals: $(DEBIAN_EXTERNALS_TARGETS) $(DEBIAN_AUDIO_TARGETS)
debian_externals_install: $(patsubst %, %_install,$(DEBIAN_EXTERNALS_TARGETS)) \ $(patsubst %, %_install,$(DEBIAN_AUDIO_TARGETS))
debian_externals_clean: $(patsubst %, %_clean,$(DEBIAN_EXTERNALS_TARGETS)) \ $(patsubst %, %_clean,$(DEBIAN_AUDIO_TARGETS))
----------------
Then we should also remove "ogg*.c" from "externals/build/src" and make "pdogg" library, with its own build targets.
This packaging is a bit difficult to categorize since libs are currently organized by author rather than by functionality. I think we should organize the pd packages by functionality, then over time, we can make libs along those lines also (like "math", "soundfile", etc.)
.hc ________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
Hello,
So here's my proposal for the layout:
pd (provided by puredata, desiredata, pd-devel, etc.) pd-doc (this may be unclear, its more like built-in help than standalone docs) pd-externals ("abstractions" and "externals" with no deps) pd-audio (anything needing extra sound libs) pd-video (virtual package for all video packages). pd-gem pd-pdp pd-pidip pd-gridflow pd-pdp
my vote for this layout, plus pd-python, pd-ruby, pd-basic ;-)),...
Then we should also remove "ogg*.c" from "externals/build/src" and make "pdogg" library, with its own build targets.
This packaging is a bit difficult to categorize since libs are currently organized by author rather than by functionality. I think we should organize the pd packages by functionality, then over time, we can make libs along those lines also (like "math", "soundfile", etc.)
thats true, since everyone wanted his playground, but I think its a kind of healthy competition, if some libraries has same functionalities, and some even have same functionalities in one library ;-), but this is an other discussion and should not be reflected by packaging.
mfg winfried ritsch
On Thu, 29 Dec 2005, Winfried Ritsch wrote:
So here's my proposal for the layout: pd (provided by puredata, desiredata, pd-devel, etc.) pd-doc (this may be unclear, its more like built-in help than standalone docs) pd-externals ("abstractions" and "externals" with no deps) pd-audio (anything needing extra sound libs) pd-video (virtual package for all video packages).
Where do you put externals that have deps that are not audio deps and that are not video deps?
pd-gridflow
my vote for this layout, plus pd-python, pd-ruby,
I don't plan to separate rubyext from GridFlow anytime soon.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Thu, 29 Dec 2005, Winfried Ritsch wrote:
So here's my proposal for the layout: pd (provided by puredata, desiredata, pd-devel, etc.) pd-doc (this may be unclear, its more like built-in help than standalone docs) pd-externals ("abstractions" and "externals" with no deps) pd-audio (anything needing extra sound libs) pd-video (virtual package for all video packages).
Where do you put externals that have deps that are not audio deps and that are not video deps?
Do you have a suggestion?
However I don't see this as being a real problem. pd-externals may have some extra dependencies, and there aren't that many externals yet which use a lot of special stuff. Some networking code may come to mind or externals which communicate with special hardware like hid. I'd just put these in pd-externals anyway, unless they, like Gridflow, pdp or Gem, form a kind of application itself build on top of Pd.
A bigger issue could be platform specific externals. Okay, Framesteins seems deadish, but for example the alsa-externals by IOhannes won't run on OS-X or MS-Windows.
Ciao
On Thu, 29 Dec 2005, Frank Barknecht wrote:
On Thu, 29 Dec 2005, Winfried Ritsch wrote:
pd-externals ("abstractions" and "externals" with no deps)
Where do you put externals that have deps that are not audio deps and that are not video deps?
Do you have a suggestion?
I don't know...
pd-externals may have some extra dependencies,
Oh, I didn't think of interpreting "externals with no deps" this way.
I'd just put these in pd-externals anyway, unless they, like Gridflow, pdp or Gem, form a kind of application itself build on top of Pd.
What do you mean that they form a kind of application? That seems vague... Is it because of their size? or is it because all three happen to define their own datatypes and use them a lot, and as such seem to be escaping Pd's claws?
What is required for a library to be considered a real library (integrated with pd) instead of being kind of an application (build on top) ? Does the distinction exist?
A bigger issue could be platform specific externals. Okay, Framesteins seems deadish, but for example the alsa-externals by IOhannes won't run on OS-X or MS-Windows.
How would that be a bigger issue, or even an issue?... You just don't provide alsa packages on OSX and MSW, that's all, right??
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Thu, 29 Dec 2005, Frank Barknecht wrote:
On Thu, 29 Dec 2005, Winfried Ritsch wrote:
pd-externals ("abstractions" and "externals" with no deps)
Where do you put externals that have deps that are not audio deps and that are not video deps?
Do you have a suggestion?
I don't know...
I can see: Your mail contains almost only sentences ending in question marks. ;) I know, asking is important, but trying to suggest answers also is.
pd-externals may have some extra dependencies,
Oh, I didn't think of interpreting "externals with no deps" this way.
I was trying to refer to my proposal, where some deps would be okay for the pd-externals package.
I'd just put these in pd-externals anyway, unless they, like Gridflow, pdp or Gem, form a kind of application itself build on top of Pd.
What do you mean that they form a kind of application? That seems vague... Is it because of their size? or is it because all three happen to define their own datatypes and use them a lot, and as such seem to be escaping Pd's claws?
Of course it's vague, that's characteristic for the problem at hand which is rather ill-defined. I don't see a precise border between several groups of externals, so I try to draw a broader picture without fragmenting stuff too much. One of the guidelines could be, how much the various groups of externals communicate with each other. All Gem-objects communicate a lot with each other, as do the pdp-objects. OTOH they don't communicate much with audio objects per se.
Viewed like that splitting off Gem and pdp to be in their own packages seperate from the others feels natural to me. The added bonus is, that we could also get rid of lots of dependencies for the pd-externals package. But even if not, I would be in favour of putting Gem and pdp into their own packages.
A bigger issue could be platform specific externals. Okay, Framesteins seems deadish, but for example the alsa-externals by IOhannes won't run on OS-X or MS-Windows.
How would that be a bigger issue, or even an issue?... You just don't provide alsa packages on OSX and MSW, that's all, right??
Well, maybe it's not an issue. It depends on if we would like to have the same set of externals in every pd-xyz package independent of platform. If yes, then maybe pd-win, pd-lin, pd-mac packages would be needed to collect the externals specific for every platform, and keep pd-externals OS-agnostic (if that would even be possible).
Ciao
-
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard -
Winfried Ritsch