Re: Thoughts on pd object packaging - use of cdbs might be preferable?
On Nov 12, 2010, at 12:30 PM, IOhannes zmölnig wrote: On 11/12/2010 06:10 PM, Hans-Christoph Steiner wrote: Ah yes, still learning my way around all the Debian tools, they are pretty large. A common snippet would be great, no argument here. so now, we only have to do it :-) About the HURD/kFreeBSD issue, it seems to be a linking issue, do we have to handle the linking differently with those kernels? I guess the Makefile is lacking uname detection for those kernels, since its looking for 'Linux'. Hopefully just using the same settings for the other two kernels will work. yes, i think the only problem is that the Makefile thinks that it is compiling for an unknown target os (because uname returns something unknown), thus no CFLAGS, LDFLAGS,... are defined which means the defaults: the .c files are compiled as applications, which obviously won't work at all. and yes, you should be able to use the very same flags as on linux (and see the other thread why it might be a good idea to keep pd_linux as the filename extension for all debian) Works for me. I have a bunch of deadlines so I won't be able to touch this for a while. That's why I just had a big rush of work: I wanted to get it in before I was saddled with lots of things. .hc "[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
On 11/12/2010 06:10 PM, Hans-Christoph Steiner wrote: > Ah yes, still learning my way around all the Debian tools, they are > pretty large. A common snippet would be great, no argument here. so now, we only have to do it :-) > About the HURD/kFreeBSD issue, it seems to be a linking issue, do we > have to handle the linking differently with those kernels? I guess the > Makefile is lacking uname detection for those kernels, since its looking > for 'Linux'. Hopefully just using the same settings for the other two > kernels will work. yes, i think the only problem is that the Makefile thinks that it is compiling for an unknown target os (because uname returns something unknown), thus no CFLAGS, LDFLAGS,... are defined which means the defaults: the .c files are compiled as applications, which obviously won't work at all. and yes, you should be able to use the very same flags as on linux (and see the other thread why it might be a good idea to keep pd_linux as the filename extension for all debian) fgmasr IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
On Nov 12, 2010, at 4:43 AM, IOhannes zmölnig wrote: On 11/11/2010 08:30 PM, Hans-Christoph Steiner wrote: I'd like to have my packages work on all Debian platforms, but I have never worked with hurd or kfreebsd, nor have had any feedback that there are problems. As far as I can tell, my packages build on all Debian platforms. just call the build-logs for any of those packages. e.g. https://buildd.debian.org/status/package.php?p=pd-motex but this was just meant as an example for the added benefit of using a common cdbs/dh/.. snippet. Ah yes, still learning my way around all the Debian tools, they are pretty large. A common snippet would be great, no argument here. About the HURD/kFreeBSD issue, it seems to be a linking issue, do we have to handle the linking differently with those kernels? I guess the Makefile is lacking uname detection for those kernels, since its looking for 'Linux'. Hopefully just using the same settings for the other two kernels will work. .hc "We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
On 11/11/2010 08:30 PM, Hans-Christoph Steiner wrote: > > I'd like to have my packages work on all Debian platforms, but I have > never worked with hurd or kfreebsd, nor have had any feedback that there > are problems. As far as I can tell, my packages build on all Debian > platforms. just call the build-logs for any of those packages. e.g. https://buildd.debian.org/status/package.php?p=pd-motex but this was just meant as an example for the added benefit of using a common cdbs/dh/.. snippet. fgmarsd IOhannes signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
On Nov 11, 2010, at 3:09 AM, Jonas Smedegaard wrote: On Wed, Nov 10, 2010 at 10:18:44PM -0500, Hans-Christoph Steiner wrote: On Wed, 2010-11-10 at 20:27 -0300, Felipe Sateler wrote: Given that most pd libraries use the same template, I think we can leverage the use of cdbs here: 1. We ship (eg, in puredata-dev) a standard-pd-object.mk CDBS class which includes the snippets needed for the shlibdeps and license fiddling, and the makefile class. 2. rules files then become simply: #!/usr/bin/make -f LIBRARY_NAME = pdlib include /usr/share/cdbs/1/rules/standard-pd-object.mk What do you think? That looks very handy, but I think the given library template is well tuned. For me the problem would be then learning cdbs for special cases. But since there are still at least 30 unpackaged Pd libraries, I think having this as option makes sense. I'd call it something like standard-pd-library.mk If the word "CDBS" discourages you, then (since the proposal is to ship a template _separately_ from CDBS) you can just ship a snippet unrelated to CDBS. Heck, you can even ship a snippet which uses short-form dh! My point here is that there is nothing in CDBS to "learn" except for the parts that you include. So if you find the CDBS templates more of a burden than a benefit, then don't use them - write your own from scratch instead: it is simply a make inclusion (at first - over time it may grow ugly, more ugly than CDBS). (and yes, I personally favor CDBS over custom templates - no news there) - Jonas I have no problem against CDBS, indeed I have almost no experience with CDSB. Its just that I know debhelper and its working well for me, so I don't see a reason for me to switch. I won't dissuade anyone else from doing this tho, it sounds like a good idea. .hc "A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
I'd like to have my packages work on all Debian platforms, but I have never worked with hurd or kfreebsd, nor have had any feedback that there are problems. As far as I can tell, my packages build on all Debian platforms. All I can say is: patches welcome. .hc On Nov 11, 2010, at 3:49 AM, IOhannes m zmoelnig wrote: On 2010-11-11 09:09, Jonas Smedegaard wrote: include /usr/share/cdbs/1/rules/standard-pd-object.mk What do you think? That looks very handy, but I think the given library template is well tuned. well, i think the template library Makefile fails on the the kfreebsd and hurd platforms (at least according to the build logs). i understand that these platforms are not the main targets, but since we are on debian, there is no good reason to not include them. a common makefile snippet could help a lot (also on debian-derivatives that have x86 derived architectures (e.g. i686), that could benefit from enabling optimzations globally (think SIMD)) the above looks a bit ironic to me... within the pd-community i guess that i was (and am) one of the stronger advocates of self-contained build-systems (there has been loads of discussion on whether it is better to use a single Makefile for all (or most) libraries or whether each library should have there own cloned makefile. the "library template Makefile" is basically the outcome of the latter, and allows each library to build without having to download the entire repository. however, i think that those problems mainly arose because there is no way to define build-dependency in a cross-platform way for ordinary Pd-packages. since now we are in the good position that we are talking about debian, we actually have the possibility to use build-dependencies and i don't see a reason to not do that. For me the problem would be then learning cdbs for special cases. But since there are still at least 30 unpackaged Pd libraries, I think having this as option makes sense. I'd call it something like standard-pd-library.mk well, one practical problem would obviously be, that there currently is no "puredata-dev" package yet, and it is unlikely to come before the upstream release of Pd-0.43 (which was due in august, but was delayed since then). would it make sense to create a separate package (e.g. "puredata-debian-dev") for the sole purpose of centralizing the makefile snippets? this package could then include cdbs, dh,... so people could have their pick. fgmasdr IOhannes ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
On 2010-11-11 09:09, Jonas Smedegaard wrote: >>> >>> include /usr/share/cdbs/1/rules/standard-pd-object.mk >>> >>> What do you think? >> >> That looks very handy, but I think the given library template is well >> tuned. well, i think the template library Makefile fails on the the kfreebsd and hurd platforms (at least according to the build logs). i understand that these platforms are not the main targets, but since we are on debian, there is no good reason to not include them. a common makefile snippet could help a lot (also on debian-derivatives that have x86 derived architectures (e.g. i686), that could benefit from enabling optimzations globally (think SIMD)) the above looks a bit ironic to me... within the pd-community i guess that i was (and am) one of the stronger advocates of self-contained build-systems (there has been loads of discussion on whether it is better to use a single Makefile for all (or most) libraries or whether each library should have there own cloned makefile. the "library template Makefile" is basically the outcome of the latter, and allows each library to build without having to download the entire repository. however, i think that those problems mainly arose because there is no way to define build-dependency in a cross-platform way for ordinary Pd-packages. since now we are in the good position that we are talking about debian, we actually have the possibility to use build-dependencies and i don't see a reason to not do that. >For me the problem would be then learning cdbs for special >> cases. But since there are still at least 30 unpackaged Pd libraries, I >> think having this as option makes sense. I'd call it something like >> standard-pd-library.mk well, one practical problem would obviously be, that there currently is no "puredata-dev" package yet, and it is unlikely to come before the upstream release of Pd-0.43 (which was due in august, but was delayed since then). would it make sense to create a separate package (e.g. "puredata-debian-dev") for the sole purpose of centralizing the makefile snippets? this package could then include cdbs, dh,... so people could have their pick. fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
On Wed, Nov 10, 2010 at 10:18:44PM -0500, Hans-Christoph Steiner wrote: On Wed, 2010-11-10 at 20:27 -0300, Felipe Sateler wrote: Given that most pd libraries use the same template, I think we can leverage the use of cdbs here: 1. We ship (eg, in puredata-dev) a standard-pd-object.mk CDBS class which includes the snippets needed for the shlibdeps and license fiddling, and the makefile class. 2. rules files then become simply: #!/usr/bin/make -f LIBRARY_NAME = pdlib include /usr/share/cdbs/1/rules/standard-pd-object.mk What do you think? That looks very handy, but I think the given library template is well tuned. For me the problem would be then learning cdbs for special cases. But since there are still at least 30 unpackaged Pd libraries, I think having this as option makes sense. I'd call it something like standard-pd-library.mk If the word "CDBS" discourages you, then (since the proposal is to ship a template _separately_ from CDBS) you can just ship a snippet unrelated to CDBS. Heck, you can even ship a snippet which uses short-form dh! My point here is that there is nothing in CDBS to "learn" except for the parts that you include. So if you find the CDBS templates more of a burden than a benefit, then don't use them - write your own from scratch instead: it is simply a make inclusion (at first - over time it may grow ugly, more ugly than CDBS). (and yes, I personally favor CDBS over custom templates - no news there) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Thoughts on pd object packaging - use of cdbs might be preferable?
On Wed, 2010-11-10 at 20:27 -0300, Felipe Sateler wrote: > Given that most pd libraries use the same template, I think we can > leverage the use of cdbs here: > > 1. We ship (eg, in puredata-dev) a standard-pd-object.mk CDBS class > which includes the snippets needed for the shlibdeps and license > fiddling, and the makefile class. > 2. rules files then become simply: > > #!/usr/bin/make -f > > LIBRARY_NAME = pdlib > > include /usr/share/cdbs/1/rules/standard-pd-object.mk > > > > What do you think? That looks very handy, but I think the given library template is well tuned. For me the problem would be then learning cdbs for special cases. But since there are still at least 30 unpackaged Pd libraries, I think having this as option makes sense. I'd call it something like standard-pd-library.mk .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
