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