Re: [PD-dev] flext
Hans-Christoph Steiner wrote: yes, check ext13 externals/Makefile for example. yes yes, i know the makefile template well, what i'm interested in is more a proposal/example for how different environments will package these templated libs, dpkg/rpm/zip/dmg/etc, what wrapper scripts will be needed? how will modularized libdirs get installed in environments like mac and windows? thomas maintains his own buildsystem and as much as its apparently stumped a bunch of people in the past, it is designed for cross platform AND max/msp. to redesign an entire build system to fit a template, for sake of maintaining some design rules seems a little over the top, that's why i decided to simply wrap it. besides, the flext layer has enough complexity to require a decent autoconf first, and if recent threads are correct, there's no libdir based autoconf template. A libdir autoconf template would be awesome to have though. Building C or C++ objects for Pd isn't hard. What about flext makes things so complicated? In the process of making that template Makefile, I realized that autotools is really rarely needed for externals. Only really when there are a lot of library dependencies. flext is a library dependecy! flext itself is a programming interface to create a standard api between pd + max/msp, the library and its headers need to be installed in a known path and thus becomes a dependency to any library using flext. additionally it has optional simd sse/altivec optimizations, and can be extended further with sndobj and stk (synthesis tookit). the current flext buildsys compiles the libs reliant on flext from a single build script, using definitions set in each libs src folder (package.txt), thus each lib is aware of the environment settings that flext was compiled with and some libs (eg. py/ext) require the user to manipulate an additional configuration file to define other system settings. i concede that it may be possible to make some libs easily conform to the makefile template, but then the pd template is rather useless for building the same lib for max/msp, which if i recall is a popular reason for using flext in the first place. The core idea is to avoid one-size-fits-all by decentralizing the libraries. If libraries are really easy to make, distribute and install, then there isn't a strong need to have all the libraries included in Pd-extended itself. People can maintain their libraries entirely separately, removing the unavoidable roadblocks that happen when things get centralized. hang on! you are decentralizing building (back to) a makefile in each directory, and the makefile is based on a template, which according to 'you shouldn't need to edit anything below here' appears to be a 'one-size-fits-all' approach. this is good and all, and i totally undestand the idea and necessity, but the problem i see occuring is when people do begin to edit below the line to accomodate a slightly more demanding build technique. what happens when the template itself needs updating - a sed script to find and replace every instance, hoping that someone hasn't made a minor alteration? currently its quite simple to make those sort of changes very swiftly, as the build directives are centralized and one change effects the whole pack. i'm just a little worried that the modular template may become more difficult to maintain in the long term. For Pd-extended 0.43, I think we should be removing a bunch of libraries that are not really used or maintained and make them separately distributed. You can see some idea of the plans here: http://puredata.info/dev/NextRelease That said, there is value to having a default set of libraries that you know will always be included with Pd-extended. I think to get to that point, libraries need to be very stable both in terms of their interface/features and their bugginess. Think of python libraries, or ruby, etc. essentially what you wish to include with pd-X is your choice and you set the flavour of that release. thats one of many benefits of decentralized packaging, there's great scope in building unique virtual targets for more niche audiences - ie, a pd for matrix maths, a pd for hardware interfaces, a pd for audio analysis and mapping, a pd for visual artists and vjs etc etc etc.. but code maturity is a difficult call, and i think an interesting working bee would be itemizing and orphaning problem objects and libs, finding duplicate behaviour and seeing what niche demand there is for legacy buggy code. that way regardless of flavour the objects being distributed will yeild the best possible results for the user. -dmotd ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] flext
On Jul 2, 2010, at 2:06 AM, dmotd wrote: Hans-Christoph Steiner wrote: yes, check ext13 externals/Makefile for example. yes yes, i know the makefile template well, what i'm interested in is more a proposal/example for how different environments will package these templated libs, dpkg/rpm/zip/dmg/etc, what wrapper scripts will be needed? Check out the template library mentioned in the MakefileTemplate page, it is a working debian package. I'm currently working with someone to make it do RPMs too. Also, all of the libs mentioned in that page are also debian packages. how will modularized libdirs get installed in environments like mac and windows? Take your pick: a) run 'make' then zip up the folder for people to copy into ~/Library/ Pd, ~/pd-externals, etc. b) run 'make' then copy the library folder in ~/Library/Pd, ~/pd- externals, etc. c) run 'make install' and it'll install into ~/Library/Pd, ~/pd- externals, etc. thomas maintains his own buildsystem and as much as its apparently stumped a bunch of people in the past, it is designed for cross platform AND max/msp. to redesign an entire build system to fit a template, for sake of maintaining some design rules seems a little over the top, that's why i decided to simply wrap it. besides, the flext layer has enough complexity to require a decent autoconf first, and if recent threads are correct, there's no libdir based autoconf template. A libdir autoconf template would be awesome to have though. Building C or C++ objects for Pd isn't hard. What about flext makes things so complicated? In the process of making that template Makefile, I realized that autotools is really rarely needed for externals. Only really when there are a lot of library dependencies. flext is a library dependecy! flext itself is a programming interface to create a standard api between pd + max/msp, the library and its headers need to be installed in a known path and thus becomes a dependency to any library using flext. additionally it has optional simd sse/altivec optimizations, and can be extended further with sndobj and stk (synthesis tookit). the current flext buildsys compiles the libs reliant on flext from a single build script, using definitions set in each libs src folder (package.txt), thus each lib is aware of the environment settings that flext was compiled with and some libs (eg. py/ext) require the user to manipulate an additional configuration file to define other system settings. i concede that it may be possible to make some libs easily conform to the makefile template, but then the pd template is rather useless for building the same lib for max/msp, which if i recall is a popular reason for using flext in the first place. Ah, more complicated than I thought. The other idea is to just make the flext build system create libdirs using its equivalent of 'make install'. Then if it respects $DESTDIR and $prefix, it'll work with the Pd-extended build system too. The core idea is to avoid one-size-fits-all by decentralizing the libraries. If libraries are really easy to make, distribute and install, then there isn't a strong need to have all the libraries included in Pd-extended itself. People can maintain their libraries entirely separately, removing the unavoidable roadblocks that happen when things get centralized. hang on! you are decentralizing building (back to) a makefile in each directory, and the makefile is based on a template, which according to 'you shouldn't need to edit anything below here' appears to be a 'one-size-fits-all' approach. this is good and all, and i totally undestand the idea and necessity, but the problem i see occuring is when people do begin to edit below the line to accomodate a slightly more demanding build technique. what happens when the template itself needs updating - a sed script to find and replace every instance, hoping that someone hasn't made a minor alteration? currently its quite simple to make those sort of changes very swiftly, as the build directives are centralized and one change effects the whole pack. i'm just a little worried that the modular template may become more difficult to maintain in the long term. Most Pd libraries do not have dependencies outside of Pd and the core C libs. It is for those cases that this Makefile template is for. The next step is to make an autotools template for more complicated situations. Also, the Makefile is versioned, and its easy enough to ship 'diff - uw' patches to update the Makefile within a library. I've done that a few times already. .hc For Pd-extended 0.43, I think we should be removing a bunch of libraries that are not really used or maintained and make them separately distributed. You can see some idea of the plans here: http://puredata.info/dev/NextRelease That said, there is value to having a default set of libraries that you know will always be included with Pd-extended. I think to get to that point,
Re: [PD-dev] Join the Compile Farm (was Re: 64-bit build for, Windows?)
Hello everyone, I'm new here. I've offered to help with the Windows 64bit build. I'm really new to compiling software, so I'll probalby need some help to get started. If you think this is unmanageable for a beginner don't be afraid to tell me so. I have some good will and patience, but I don't want to waste anyone's time. :) I'm reading the MinGW-w64 pages on Sourceforge. I should be looking for a native compiler for w64, but I can't seem to find any. I suppose since it's a native compiler I can build it myself. Is this correct. Then, should I download a tarball and compile from the source? Otherwise I found what seems to be a native version here: http://www.drangon.org/mingw/ I cannont find either the MinGW-get installer mentioned on the 32bit version of the instructions. I suppose there is nothing similar for the 64bit version for the time being. I suppose I have to get Cygwin for compilation too. Anything I should pay special attention to concerning this? Thanks for your help Pierre-Olivier On 02/07/2010 22:46, Hans-Christoph Steiner wrote: A Windows 7 build sounds like a good idea. The first place to start is getting a MinGW-w64 build environment setup. If you get that installed, then first try just building the core of pd-extended without all the libraries. That shouldn't be too hard to get going. http://mingw-w64.sourceforge.net/ Here is the whole instructions for the 32-bit environment: http://puredata.info/docs/developer/WindowsMinGW Perhaps it makes sense to continue this discussion on pd-dev? .hc On Jul 1, 2010, at 4:56 PM, Pierre-Olivier Boulant wrote: Hello, I've been using Puredata for a year now and I'd be glad to help with the new release. I'll be getting a new computer for performances in the coming up week. It will be an Asus N82 (it's not on their website at the moment). Intel Core i7 - 720QM (quad core) with 4GB of RAM an Nvidia Geforce GT335M The OS is a Windows 7 64bit. I might install some linux distro too alongside the original OS. I can leave the computer on as much as needed for the autobuild process. I will use the computer for my own too. But I can leave it on at night. I don't know if you want specifically Windows XP or if Windows 7 which is more and more widespread now can do too. You can contact me with this email or with skype (same email address). Cheers Pierre-Olivier -- ~Pierre-Olivier Boulant ~ -o- www.puffskydd.net -o- ~ www.flickr.com/pob31/sets ~ -o-www.lepixophone.net-o- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
