[PD-dev] any2string problem

[Bryan Jurish]

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)...

> 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 ;-)

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

marmosets,
	Bryan

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