[PD-dev] flext

[Hans-Christoph Steiner]

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, 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



----------------------------------------------------------------------------

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war on  
terrorism.        - retired U.S. Army general, William Odom