Re: [PD] compiling pluginhost~ on Ubuntu/Mint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-10-10 22:24, Hans-Christoph Steiner wrote: On Oct 10, 2012, at 1:18 PM, Jamie Bullock wrote: Anyhow, to conform to the policies and conventions of the Pd svn, I've removed the headers and added the requisite instructions to the README as suggested. while i agree with hans that those 3rd party headers would better not be in svn, there is really no policy enforcing that. So if you really want, I'm ok with you putting the headers that were in include/ directly into pluginhost~. Then you won't need the -Iinclude. opinions here differ: if you really want to add those 3rd party headers to the SVN, then *I'd* suggest to leave them in a separate directory, in order to keep your sources and 3rd party sources apart. My issue is about putting those external headers in the 'make dist' tarball. This setup would allow people to build using those headers if they checked out via SVN, but if they download the source tarball from the release, they'd need to get those headers from an 'official' source. That official source could also be downloading the source tarballs and copying them into place. hmm, but this seems even weirder to me. people who are using svn checkouts, are most likely up for some extra exercises. they already installed subversion, why would it bother them to install some random dev-package? otoh, people who are using the dist tarball, cannot even be expected to run autoconf. (expectation is always very subjective, so i don't expect people to have the same expectations when downloading from svn or tarballs, it's still true though, that in my experience building from a repository is usually a bit less convenient than building from a release tarball) anyhow: the pd-extended way for handling 3rd-party libraries in svn seems to add the full 3rd party library sources into [1], so on the Pd-extended build machines you can expect those libraries to be present. another possibility would be provide the headers (even in dist), but make the use of those headers optional, to the extend that the default is not to use those headers (and instead use the system-installed or fail) and people have to take active steps to enable those headers, following detailed instructions in README.txt tgamsdr IOhannes [1] http://pure-data.svn.sourceforge.net/viewvc/pure-data/sources/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlB2b/IACgkQkX2Xpv6ydvSuKACeI6YiJSe6TmJzwuOjhwnmsNAM jkYAoMs1/SIxjwCNHAMWKP6A4l95wwyU =NqSJ -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] compiling pluginhost~ on Ubuntu/Mint
On 10 Oct 2012, at 21:24, Hans-Christoph Steiner h...@at.or.at wrote: I've got mixed feelings about this. It's clearly much preferrable to do it this way on Linux distros, which provide these packages. On Mac it's a minor headache to 1. install a package manager 2. install the dependencies 3. make sure the build system can find the dependencies On Windows: ?? OTOH, for the sake of including 3 headers in svn, everyone could just type make, and they're done. Anyhow, to conform to the policies and conventions of the Pd svn, I've removed the headers and added the requisite instructions to the README as suggested. I've seen people include external headers many times over the years, and I've also seen bugs arise because of it, because those included headers were out of date, and the person building didn't realized that the project included its own version of the header rather than using the 'official' one. The question to answer is: who are the people going to be building this from source? The vast majority of users will want to download the binaries and never even think about the source code. From my experience, I would guess that people who would want to compile it themselves will likely be interested in DSSI and LADSPA for other things also, and therefore will need to have those headers in a simple place for other projects too. I probably came across as more grumpy about this than I actually am! I agree with the exact points you've made here, but I can also think of cases where it's more desirable to commit things to svn. I tend to take a pragmatic view, weighing up the reasons for / against on a case-by-case basis. In this specific case I think you're right that the people compiling from source are likely to be on either a Linux audio box or Mac with Fink / MacPorts / Homebrew so I'm perfectly happy with the decision to remove the headers :) Does pluginhost~ work on Windows? I didn't realize that. Does anyone distribute dssi or ladspa binaries for Windows? It *should* work on Windows. The Audacity project provides a bunch of LADSPA plugins for Windows: http://wiki.audacityteam.org/index.php?title=Ladspa_Plug-ins pluginhost~ doesn't require that the UI part of DSSI is running, so it should make it possible to run some of the synths under Windows with no GUI. Jamie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] compiling pluginhost~ on Ubuntu/Mint
On 10/11/2012 10:11 AM, Jamie Bullock wrote: On 10 Oct 2012, at 21:24, Hans-Christoph Steiner h...@at.or.at wrote: I've got mixed feelings about this. It's clearly much preferrable to do it this way on Linux distros, which provide these packages. On Mac it's a minor headache to 1. install a package manager 2. install the dependencies 3. make sure the build system can find the dependencies On Windows: ?? OTOH, for the sake of including 3 headers in svn, everyone could just type make, and they're done. Anyhow, to conform to the policies and conventions of the Pd svn, I've removed the headers and added the requisite instructions to the README as suggested. I've seen people include external headers many times over the years, and I've also seen bugs arise because of it, because those included headers were out of date, and the person building didn't realized that the project included its own version of the header rather than using the 'official' one. The question to answer is: who are the people going to be building this from source? The vast majority of users will want to download the binaries and never even think about the source code. From my experience, I would guess that people who would want to compile it themselves will likely be interested in DSSI and LADSPA for other things also, and therefore will need to have those headers in a simple place for other projects too. I probably came across as more grumpy about this than I actually am! I agree with the exact points you've made here, but I can also think of cases where it's more desirable to commit things to svn. I tend to take a pragmatic view, weighing up the reasons for / against on a case-by-case basis. In this specific case I think you're right that the people compiling from source are likely to be on either a Linux audio box or Mac with Fink / MacPorts / Homebrew so I'm perfectly happy with the decision to remove the headers :) Does pluginhost~ work on Windows? I didn't realize that. Does anyone distribute dssi or ladspa binaries for Windows? It *should* work on Windows. The Audacity project provides a bunch of LADSPA plugins for Windows: http://wiki.audacityteam.org/index.php?title=Ladspa_Plug-ins pluginhost~ doesn't require that the UI part of DSSI is running, so it should make it possible to run some of the synths under Windows with no GUI. Jamie Ok, if you're ready to make a 1.0 release: http://puredata.info/docs/developer/MakingALibraryRelease Let me know once the tarball is posted, and I'll make the 'official' Debian package. I'll keep the packaging stuff (i.e. the debian/ folder) in a separate repo in the Debian pkg-multimedia team's git repo. Do you want to keep the debian/ folder in your SVN folder? I normally delete it, but its fine to keep it there, as long as you're aware that I won't be updating it there anymore, but only in the pkg-multimedia git. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] compiling pluginhost~ on Ubuntu/Mint
On 10 Oct 2012, at 01:15, Hans-Christoph Steiner h...@at.or.at wrote: That fixed it. I just updated the Makefile to the latest version from the template. It now allows you to include the extra sources without having to modify the Makefile. It also has better support for building on Mac OS X = 10.7, since Xcode 4.x doesn't install the PowerPC tools by default. Great! I've just updated the Makefile so if looks in the include/ directory for headers as before. See svn 16376. Also, I noticed that some of the liblo code says it has a CPL license. It seems that code is not compatible with the GPL: https://en.wikipedia.org/wiki/Common_Public_License That was a typo. The version of liblo I took the code from was GPL v2. The website of liblo says its under the LGPL, which would be compatible. That's something that will need to be clarified before this can be uploaded to Debian. I've now added clarification to handlers_osc.c For the BSD-licensed code, the BSD license does have one requirement: that you include the original license file. You can just append it to the LICENSE.txt file. I've now added the necessary BSD inclusion to the affected .c files, it's only four lines. Generally tidied up all included licensing information so everything is clear and GPL-compatible in svn revision 16375. I just committed the debian-izing. If you want to try it, do this: sudo apt-get install debhelper devscripts dpkg-dev cd /path/to/externals/postlude/pluginhost~ make dist mv pluginhost~-1.0.tar.gz ../pd-pluginhost_1.0.orig.tar.gz debuild -uc -us Great. I don't have a Linux box around right now, but thanks for doing this. Jamie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] compiling pluginhost~ on Ubuntu/Mint
On Oct 10, 2012, at 6:11 AM, Jamie Bullock wrote: On 10 Oct 2012, at 01:15, Hans-Christoph Steiner h...@at.or.at wrote: That fixed it. I just updated the Makefile to the latest version from the template. It now allows you to include the extra sources without having to modify the Makefile. It also has better support for building on Mac OS X = 10.7, since Xcode 4.x doesn't install the PowerPC tools by default. Great! I've just updated the Makefile so if looks in the include/ directory for headers as before. See svn 16376. It would be much preferrable if those headers were removed from the SVN and instead the README.txt included instructions for installing the packages needed to get those headers. Its actually against Debian policy to include files in a package that already exist in another package. For example, on Debian-derivs, its: sudo apt-get install dssi-dev libasound2-dev ladspa-sdk For Fink on Mac OS X, its: fink install dssi-dev libdssialsacompat ladspa-dev I'll bet MacPorts also has those packages. Also, I noticed that some of the liblo code says it has a CPL license. It seems that code is not compatible with the GPL: https://en.wikipedia.org/wiki/Common_Public_License That was a typo. The version of liblo I took the code from was GPL v2. The website of liblo says its under the LGPL, which would be compatible. That's something that will need to be clarified before this can be uploaded to Debian. I've now added clarification to handlers_osc.c For the BSD-licensed code, the BSD license does have one requirement: that you include the original license file. You can just append it to the LICENSE.txt file. I've now added the necessary BSD inclusion to the affected .c files, it's only four lines. Generally tidied up all included licensing information so everything is clear and GPL-compatible in svn revision 16375. I just committed the debian-izing. If you want to try it, do this: sudo apt-get install debhelper devscripts dpkg-dev cd /path/to/externals/postlude/pluginhost~ make dist mv pluginhost~-1.0.tar.gz ../pd-pluginhost_1.0.orig.tar.gz debuild -uc -us Great. I don't have a Linux box around right now, but thanks for doing this. The licensing stuff was probably the only blocker for uploading to Debian, so once you make a 1.0 release, that should be pretty straightforward. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] compiling pluginhost~ on Ubuntu/Mint
On 10 Oct 2012, at 16:04, Hans-Christoph Steiner h...@at.or.at wrote: Great! I've just updated the Makefile so if looks in the include/ directory for headers as before. See svn 16376. It would be much preferrable if those headers were removed from the SVN and instead the README.txt included instructions for installing the packages needed to get those headers. Its actually against Debian policy to include files in a package that already exist in another package. For example, on Debian-derivs, its: I've got mixed feelings about this. It's clearly much preferrable to do it this way on Linux distros, which provide these packages. On Mac it's a minor headache to 1. install a package manager 2. install the dependencies 3. make sure the build system can find the dependencies On Windows: ?? OTOH, for the sake of including 3 headers in svn, everyone could just type make, and they're done. Anyhow, to conform to the policies and conventions of the Pd svn, I've removed the headers and added the requisite instructions to the README as suggested. The licensing stuff was probably the only blocker for uploading to Debian, so once you make a 1.0 release, that should be pretty straightforward. I've just bumped the version number to 1.0. svn 16380. best, Jamie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] compiling pluginhost~ on Ubuntu/Mint
On Oct 10, 2012, at 1:18 PM, Jamie Bullock wrote: On 10 Oct 2012, at 16:04, Hans-Christoph Steiner h...@at.or.at wrote: Great! I've just updated the Makefile so if looks in the include/ directory for headers as before. See svn 16376. It would be much preferrable if those headers were removed from the SVN and instead the README.txt included instructions for installing the packages needed to get those headers. Its actually against Debian policy to include files in a package that already exist in another package. For example, on Debian-derivs, its: I've got mixed feelings about this. It's clearly much preferrable to do it this way on Linux distros, which provide these packages. On Mac it's a minor headache to 1. install a package manager 2. install the dependencies 3. make sure the build system can find the dependencies On Windows: ?? OTOH, for the sake of including 3 headers in svn, everyone could just type make, and they're done. Anyhow, to conform to the policies and conventions of the Pd svn, I've removed the headers and added the requisite instructions to the README as suggested. I've seen people include external headers many times over the years, and I've also seen bugs arise because of it, because those included headers were out of date, and the person building didn't realized that the project included its own version of the header rather than using the 'official' one. The question to answer is: who are the people going to be building this from source? The vast majority of users will want to download the binaries and never even think about the source code. From my experience, I would guess that people who would want to compile it themselves will likely be interested in DSSI and LADSPA for other things also, and therefore will need to have those headers in a simple place for other projects too. Does pluginhost~ work on Windows? I didn't realize that. Does anyone distribute dssi or ladspa binaries for Windows? Do Mac OS X devs work without macports, fink, or homebrew? I personally cannot imagine using Mac OS X for C development without Fink. Its Debian policy, not Pd policy, you can have the headers in SVN if you want :). Just making the build rely on them there makes it a pain to package it for Debian. So if you really want, I'm ok with you putting the headers that were in include/ directly into pluginhost~. Then you won't need the -Iinclude. My issue is about putting those external headers in the 'make dist' tarball. This setup would allow people to build using those headers if they checked out via SVN, but if they download the source tarball from the release, they'd need to get those headers from an 'official' source. That official source could also be downloading the source tarballs and copying them into place. Or there are other possible approaches as well. .hc The licensing stuff was probably the only blocker for uploading to Debian, so once you make a 1.0 release, that should be pretty straightforward. I've just bumped the version number to 1.0. svn 16380. best, Jamie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] compiling pluginhost~ on Ubuntu/Mint
I just tried to compile pluginhost~ on my Mint install. I have dssi-dev and ladspa-sdk installed. I just ran make and got: hans@palatschinken pluginhost~ $ make cc -I/usr/local/include/pd -I./include -DPD -DVERSION='1.0' -DHAVE_SYS_CLOSE_AUDIO -DHAVE_SYS_CLOSE_MIDI -fPIC -Wall -W -g -g -O0 -o jsearch.o -c jsearch.c jsearch.c: In function ‘LADSPADirectoryPluginSearch’: jsearch.c:40:5: error: unknown type name ‘bool’ jsearch.c:40:20: error: ‘false’ undeclared (first use in this function) jsearch.c:40:20: note: each undeclared identifier is reported only once for each function it appears in jsearch.c:82:27: error: ‘true’ undeclared (first use in this function) make: *** [jsearch.o] Error 1 .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] compiling pluginhost~ on Ubuntu/Mint
On 9 Oct 2012, at 19:26, Hans-Christoph Steiner h...@at.or.at wrote: I just tried to compile pluginhost~ on my Mint install. I have dssi-dev and ladspa-sdk installed. I just ran make and got: hans@palatschinken pluginhost~ $ make cc -I/usr/local/include/pd -I./include -DPD -DVERSION='1.0' -DHAVE_SYS_CLOSE_AUDIO -DHAVE_SYS_CLOSE_MIDI -fPIC -Wall -W -g -g -O0 -o jsearch.o -c jsearch.c jsearch.c: In function ‘LADSPADirectoryPluginSearch’: jsearch.c:40:5: error: unknown type name ‘bool’ jsearch.c:40:20: error: ‘false’ undeclared (first use in this function) jsearch.c:40:20: note: each undeclared identifier is reported only once for each function it appears in jsearch.c:82:27: error: ‘true’ undeclared (first use in this function) make: *** [jsearch.o] Error 1 Thanks for the bug report. Just fixed it in svn revision 16368. best, Jamie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] compiling pluginhost~ on Ubuntu/Mint
On 10/09/2012 02:35 PM, Jamie Bullock wrote: On 9 Oct 2012, at 19:26, Hans-Christoph Steiner h...@at.or.at wrote: I just tried to compile pluginhost~ on my Mint install. I have dssi-dev and ladspa-sdk installed. I just ran make and got: hans@palatschinken pluginhost~ $ make cc -I/usr/local/include/pd -I./include -DPD -DVERSION='1.0' -DHAVE_SYS_CLOSE_AUDIO -DHAVE_SYS_CLOSE_MIDI -fPIC -Wall -W -g -g -O0 -o jsearch.o -c jsearch.c jsearch.c: In function ‘LADSPADirectoryPluginSearch’: jsearch.c:40:5: error: unknown type name ‘bool’ jsearch.c:40:20: error: ‘false’ undeclared (first use in this function) jsearch.c:40:20: note: each undeclared identifier is reported only once for each function it appears in jsearch.c:82:27: error: ‘true’ undeclared (first use in this function) make: *** [jsearch.o] Error 1 Thanks for the bug report. Just fixed it in svn revision 16368. That fixed it. I just updated the Makefile to the latest version from the template. It now allows you to include the extra sources without having to modify the Makefile. It also has better support for building on Mac OS X = 10.7, since Xcode 4.x doesn't install the PowerPC tools by default. Also, I noticed that some of the liblo code says it has a CPL license. It seems that code is not compatible with the GPL: https://en.wikipedia.org/wiki/Common_Public_License The website of liblo says its under the LGPL, which would be compatible. That's something that will need to be clarified before this can be uploaded to Debian. For the BSD-licensed code, the BSD license does have one requirement: that you include the original license file. You can just append it to the LICENSE.txt file. I just committed the debian-izing. If you want to try it, do this: sudo apt-get install debhelper devscripts dpkg-dev cd /path/to/externals/postlude/pluginhost~ make dist mv pluginhost~-1.0.tar.gz ../pd-pluginhost_1.0.orig.tar.gz debuild -uc -us .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
