[PD-dev] any2string problem

[Hans-Christoph Steiner]

On Jul 31, 2007, at 4:21 PM, Bryan Jurish wrote:

> moin all,
>
> warning: idle pontifications follow ;-)
>
> On 2007-07-31 20:04:34, Hans-Christoph Steiner <hans at eds.org>  
> appears to
> have written:
>> On Jul 31, 2007, at 12:56 AM, Bryan Jurish wrote:
>>> moin again,
>>> On 2007-07-31 09:43:21, IOhannes m zmoelnig <zmoelnig at iem.at>  
>>> appears
>>> to have written:
>>>> and it is rather a glitch in the assumptions the externals/build/ 
>>>> src/
>>>> makes than in the pdstring, which just builds perfectly.
>>>
>>> i don't wish to agitate slumbering canines, but it would be nice if
>>> the externals/build system and pdstring (also gfsm, readdir, etc)
>>> played nicely with one another.  I keep putting off writing default
>>> externals/build-compatibile makefiles, basically because I think
>>> there's got to be a "better" way to do it, most likely involving
>>> automake|autoconf.  any m4 hackers on the list these days?
>>>
>>> also, i seem to recall hearing or reading recently something to the
>>> effect that "multiple-object libraries are deprecated" -- is  
>>> there any
>>> knock-down drag-out argument why this should be so?
>
> ... I still haven't heard a solid argument for this one ... sorry if i
> missed it on the list previously -- anything in particular I should
> search the archives for? I realize that autoloading only currently  
> works
> (in vanilla pd at least) for object-named externals (which is why I  
> try
> to build a "dummy" library object into my libraries (a la johannes'
> dummy [zexy] object))... are there other instabilities or issues  
> i'm not
> aware of?  Even if it's just a matter of makefile pattern matching, I
> could understand it ... (although I wouldn't actually qualify makefile
> pattern matching as a "knock-down drag-out" argument)...

This has been discussed quite a bit on the lists and at the Pd Con  
1.  Here's the basic synopsis with the problems with the multi-class- 
single-file libs:

1) no way to sort out name conflicts
2) every object is loaded regardless of whether it's used.
3) does not work with namespaces (i.e. [moocow/any2string])

Plus once libdir format is more flushed out, there will also be  
embedded help, examples, etc. and a common library format regardless  
of which language the objects are written in (Pd, C, etc.)


>
>> I make no claims that what exists is a great system.  But it is far
>> better than anything else that exists.
>
> I freely admit that the pd-extended build architecture is certainly a
> working and unified system, and as such is indeed far preferable to  
> the
> veritable chaos of disparate conventions otherwise employed by the
> various external authors (myself included) -- everybody seems to  
> pretty
> much roll their own. Indeed, the externals/build directory has  
> saved me
> personally a good deal of wailing and gnashing of teeth, for which  
> i am
> eternally (> 3.4e+38 temporal units of your choice) grateful.
>
> I'm also pretty happy with the pure-make approach in build/src: I
> certainly prefer it to SCons or other make alternatives.
>
>> If someone wants to replace the
>> whole thing that would be great, as long as they first do it  
>> outside of
>> the existing system to prove it works, then it could be integrated  
>> into
>> the main builds.  There also has to be a solid, long term commitment
>> from some devs to maintain it.
>
> Aye.  There's the rub.  Not having the time myself to dive into an
> alternative, I should probably just keep my big mouth shut,  
> however... I
> haven't, so...
>
> There are various reasons (including historical) for the various build
> conventions floating about in externals/, and the pd-extended build  
> has
> to co-exist somehow with all of them (at least, with all of those  
> which
> feed into pd-extended)... and it would seem to me that a hierarchical
> build procedure (e.g. recursive descent with make) would be preferable
> to the "glob-and-guess" technique in externals/build/src, and to the
> monolithic externals/Makefile: it would allow library builds (to which
> I'm partial) as well as leaving maintainance of pd-extended build
> support entirely within the domain of the individual externals'
> maintainers... but that's just wishful thinking... I'll try and see  
> how
> to weasel my conventions into externals/Makefile without breaking
> anything ;-)

Yes, the current build system isn't elegant.  I would love to see it  
replaced by something better.  I would really hate to see it semi- 
replaced by something that doesn't get completed.


>
>> As for maintaining your code in the existing Pd-extended build  
>> system,
>> no one is obligated.  But if you add your code/library to it, then  
>> you
>> need to maintain what you have setup, IMHO.  If you want your code  
>> to be
>> distributed and work with Pd-extended, then you'll want to  
>> maintain it
>> within the Pd-extended build system.
>
> Agreed.  By the same token, though, it should be clear which bits have
> been set up by whom -- just another reason for hierarchical builds,
> really...

No argument here, someone just needs to commit to the work.

.hc

>
> marmosets,
> 	Bryan
>
> -- 
> Bryan Jurish                           "There is *always* one more  
> bug."
> jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic  
> Entomology



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

Looking at things from a more basic level, you can come up with a  
more direct solution... It may sound small in theory, but it in  
practice, it can change entire economies.     - Amy Smith