moin all,
warning: idle pontifications follow ;-)
On 2007-07-31 20:04:34, Hans-Christoph Steiner hans@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@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