I was thinking of putting up some binary releases up on the SourceForge Files section. Anyone have any objections? I know a bunch of people who are interested in learning pd but are definitely not the type to download and compile things for themselves. It would be nice to have a central location to point people at for all of the various binaries, like RPMs, MacOS X packages, Win32 package/zip.
.hc
Hi, Hans-Christoph Steiner schrieb:
I was thinking of putting up some binary releases up on the SourceForge Files section. Anyone have any objections? I know a bunch of people who are interested in learning pd but are definitely not the type to download and compile things for themselves. It would be nice to have a central location to point people at for all of the various binaries, like RPMs, MacOS X packages, Win32 package/zip.
I don't have any objections. I'd like it. Did you check out the SF build-farm? Maybe we could automate some binary building...
ciao
On Fri, 28 Feb 2003, Frank Barknecht wrote:
I don't have any objections. I'd like it. Did you check out the SF build-farm? Maybe we could automate some binary building...
This would be really cool, automatically building a weekly snapshot. We need the machines that do this, though. For Linux a Rdhat and Debian machine, one OSX and a Windows one. Maybe we should take a look what sourceforge offers in their compile farm ?
Greetings,
Guenter
On Friday, Feb 28, 2003, at 04:29 America/New_York, Frank Barknecht wrote:
Hi, Hans-Christoph Steiner schrieb:
I was thinking of putting up some binary releases up on the SourceForge Files section. Anyone have any objections? I know a bunch of people who are interested in learning pd but are definitely not the type to download and compile things for themselves. It would be nice to have a central location to point people at for all of the various binaries, like RPMs, MacOS X packages, Win32 package/zip.
I don't have any objections. I'd like it. Did you check out the SF build-farm? Maybe we could automate some binary building...
To start, I'll just put up some existing binaries, just to get the ball rolling. But the build-farm is definitely a good idea, but I don't have the time just yet to look too deeply into it.
But first, one of the pure-data.sf.net needs to grant me access to the Add/Edit Releases section so I can start doing this.
.hc
Yes, thats the idea of the CVS. I think we are close to a first release of the externals, all that is missing is the build system for windows.
Volunteers ?
Guenter
On Thu, 27 Feb 2003, Hans-Christoph Steiner wrote:
I was thinking of putting up some binary releases up on the SourceForge Files section. Anyone have any objections? I know a bunch of people who are interested in learning pd but are definitely not the type to download and compile things for themselves. It would be nice to have a central location to point people at for all of the various binaries, like RPMs, MacOS X packages, Win32 package/zip.
.hc
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hi, guenter geiger schrieb:
Yes, thats the idea of the CVS. I think we are close to a first release of the externals
Did you take a look at my extended debian/rules files that also build creb and the flext-ernals? Currently they get packed into pd-externals which is not so nice, but I never quite understood how dpkg moves files into sub-packages :(
ciao
On Fri, 28 Feb 2003, Frank Barknecht wrote:
Hi, guenter geiger schrieb:
Yes, thats the idea of the CVS. I think we are close to a first release of the externals
Did you take a look at my extended debian/rules files that also build creb and the flext-ernals? Currently they get packed into pd-externals which is not so nice, but I never quite understood how dpkg moves files into sub-packages :(
To move files, you need to write a debian/sub-package.files and add the subpackage to debian/control
I am not sure if we should release all together, or separate. If we release the flext externals we have to compile them for MAX too ?
Guenter
Hi, guenter geiger schrieb:
I am not sure if we should release all together, or separate. If we release the flext externals we have to compile them for MAX too ?
No, why should we? They compile just like any other external. You give them the target platform with a -Define. MAX-versions are impossible on Linux and Windows (currently) anyway.
ciao
On Fri, 28 Feb 2003, Frank Barknecht wrote:
Hi, guenter geiger schrieb:
I am not sure if we should release all together, or separate. If we release the flext externals we have to compile them for MAX too ?
No, why should we? They compile just like any other external. You give them the target platform with a -Define. MAX-versions are impossible on Linux and Windows (currently) anyway.
You are right, stupid question. Ok, so what we will have to do (I know we talked about this when doing the debian packages, but this release should be general for GNU/Linux.
- pd-externals (all externals that do not depend on additional libraries except libc and libm)
compiled for: * Linux * OSX * Windows
- flext - flext-externals compiled for: * Linux gcc2 * Linux gcc3 (Do we need both versions ??) * OSX * Windows
Then there are some externals left that depend on libraries (like the ogg things). Should we compile them statically ?
What else ?
Ah, yes, ask everyone if it is ok to release the code as it is now.
Document installation (or add installer scripts ?) Should we release .rpm and .debs directly ?
Well, and above all fix the Windows compilation. I might be able to do that on Monday.
Greetings,
Guenter
guenter geiger wrote:
On Fri, 28 Feb 2003, Frank Barknecht wrote:
Then there are some externals left that depend on libraries (like the ogg things). Should we compile them statically ?
it would be nice, if the linux rpm and deb packages are not linked statically with libvorbis / libogg. maybe you can do this with binaries in a tar.gz file. for windows i would prefer the dll files included in the zip.
i don't know which other externals depend on libraries.
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
Ok, so what we will have to do (I know we talked about this when doing the debian packages, but this release should be general for GNU/Linux.
- pd-externals (all externals that do not depend on additional libraries except libc and libm)
compiled for:
- Linux
- OSX
- Windows
This sounds okay. Should we include the libraries there, maybe stripped into single externals? This way, we would automatically get rid of name-conflicts like abs~.
- flext
flext can be build to depend on libsndobj and/or stk. How to deal with that? STK might have a license problem (waveguide patents,...), so maybe it cant't be included into distributions like Debian. SndObj already is in Debian (Agnula). So I see two possibilities:
a) Build flext without SndObj and STK, but maybe have an explanation in a package README, how to compile it with the two. b) Build two packages, flext-pure and flext-synthesis (or flext-stk and flext-sndobj), including both.
I could live with a), but b) would make the inclusion of my syncgrain~ external easier, which depends on flext-sndobj.
- flext-externals
compiled for:
- Linux gcc2
- Linux gcc3 (Do we need both versions ??)
- OSX
- Windows
gcc2 seems to be hard to get right with flext. As oth RedHat and Debian (don't know about OS-X) now default to g++-3.x I wouldn't bother with g++-2.x.
Then there are some externals left that depend on libraries (like the ogg things). Should we compile them statically ?
I think, statically feels wrong for Linux, but it could be the right thing to do on Windows.
Ah, yes, ask everyone if it is ok to release the code as it is now.
Document installation (or add installer scripts ?) Should we release .rpm and .debs directly ?
That's what I would prefer. Or include the debs in Debian unstable and give the rpms to Planet CCRMA.
ciao
On Sun, 2 Mar 2003, Frank Barknecht wrote:
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
Ok, so what we will have to do (I know we talked about this when doing the debian packages, but this release should be general for GNU/Linux.
- pd-externals (all externals that do not depend on additional libraries except libc and libm)
compiled for:
- Linux
- OSX
- Windows
This sounds okay. Should we include the libraries there, maybe stripped into single externals? This way, we would automatically get rid of name-conflicts like abs~.
Sorry, I do not understand what you mean. You mean externals libraries ? I am against it. If we have confilicting externals (like abs~) we will just select the best one. Thats why I have made the build directory how it is. Do you think we should inlcude libraries ?
- flext
flext can be build to depend on libsndobj and/or stk. How to deal with that? STK might have a license problem (waveguide patents,...), so maybe it cant't be included into distributions like Debian. SndObj already is in Debian (Agnula). So I see two possibilities:
a) Build flext without SndObj and STK, but maybe have an explanation in a package README, how to compile it with the two. b) Build two packages, flext-pure and flext-synthesis (or flext-stk and flext-sndobj), including both.
I could live with a), but b) would make the inclusion of my syncgrain~ external easier, which depends on flext-sndobj.
- flext-externals
compiled for:
- Linux gcc2
- Linux gcc3 (Do we need both versions ??)
- OSX
- Windows
gcc2 seems to be hard to get right with flext. As oth RedHat and Debian (don't know about OS-X) now default to g++-3.x I wouldn't bother with g++-2.x.
Then there are some externals left that depend on libraries (like the ogg things). Should we compile them statically ?
I think, statically feels wrong for Linux, but it could be the right thing to do on Windows.
Ah, yes, ask everyone if it is ok to release the code as it is now.
Document installation (or add installer scripts ?) Should we release .rpm and .debs directly ?
That's what I would prefer. Or include the debs in Debian unstable and give the rpms to Planet CCRMA.
You are right, for Linux it is probably the best to release source only, with a Debian package and Fernando's rpm we cover almost everything.
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
I am against it. If we have confilicting externals (like abs~) we will just select the best one. Thats why I have made the build directory how it is. Do you think we should inlcude libraries ?
I meant, how should we deal with the libraries. I understand, you don't want to package libraries at all, only single externals. This is fine with me, it's just a little bit more work.
I think (I didn't check out cvs for about a week or so) that currently the following libraries yet need to made it into build/:
creb grill/xsample grill/fftease grill/vasp plugin~ (?)
This can be made, I guess. I still need to take a deeper look at your build system. I guess, it doesn't cover flext-externals yet?
ciao
On Mon, 3 Mar 2003, Frank Barknecht wrote:
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
I am against it. If we have confilicting externals (like abs~) we will just select the best one. Thats why I have made the build directory how it is. Do you think we should inlcude libraries ?
I meant, how should we deal with the libraries. I understand, you don't want to package libraries at all, only single externals. This is fine with me, it's just a little bit more work.
I think (I didn't check out cvs for about a week or so) that currently the following libraries yet need to made it into build/:
creb
Yes, these are not included yet, but it should not be to hard. Just make a "link" in the build/src directory to each external that you want to compile. This is easy as long as the externals are 1 source file per external. (Look into one of the build/src files how the link is done to be platform independent).
grill/xsample grill/fftease grill/vasp
These are closely related to how we proceed with flext (versions, etc).
plugin~ (?)
yes, this will have some dependencies on windows at least, on linux it doesnt need additional libraries.
This can be made, I guess. I still need to take a deeper look at your build system. I guess, it doesn't cover flext-externals yet?
No, Ihave split the debain packages according to the build system. pd-externals just include externals that build without libraries (except ogg, which we might put into a separate package).
And yes, on windows we will have to include the .dlls that are missing, I think, on Linux we hope that they are on the system already.
Having to use additional libraries and still beeing platform independent is not an easy problem to solve. We have to decide on a case by case basis.
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
And yes, on windows we will have to include the .dlls that are missing, I think, on Linux we hope that they are on the system already.
Having to use additional libraries and still beeing platform independent is not an easy problem to solve. We have to decide on a case by case basis.
Maybe we can do a pd-support package for windows, tha has binary-dlls of the needed libraries in it, like ogg.dll, iiwusynth.dll and so on.
ciao
Hi guenter,
On 2/3/03 6:31 AM, "guenter geiger" geiger@xdv.org wrote:
Well, and above all fix the Windows compilation. I might be able to do that on Monday.
If you want to leave this to me to have a crack at, I can have a look at this tonight (Australian time).
At the moment, I'm not a registered developer for the pd externals project, so you'll need to add me if I'm to be able to submit the update.
Daniel
On Mon, 3 Mar 2003, Daniel Heckenberg wrote:
Hi guenter,
On 2/3/03 6:31 AM, "guenter geiger" geiger@xdv.org wrote:
Well, and above all fix the Windows compilation. I might be able to do that on Monday.
If you want to leave this to me to have a crack at, I can have a look at this tonight (Australian time).
At the moment, I'm not a registered developer for the pd externals project, so you'll need to add me if I'm to be able to submit the update.
Great,
Just send me your sourceforge login and I add you to the list. I am not going to start on this then, let me know if you have questions.
Guenter
-
Daniel Heckenberg -
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
smoerk