[PD-dev] flext

[dmotd]

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