On Dec 9, 2005, at 12:15 PM, Frank Barknecht wrote:
Hallo, geiger hat gesagt: // geiger wrote:
Well, I think that the real issues we suffer are social, and I am far from understanding those. For the rest, I don't know more, I just ask myself what is it that it is so hard to build externals. And I fear that we have produced the complexity by ourselves.
That's a very valid point worth to discuss somehow outside the technical realization of how to build stuff and also only limited to non-library-using, C externals. I'll call these "plain externals" now, so flext, oggamp etc. are left out. Currently these are all in the author's directories, because we were all too frightened to put all our valued stuff together into one big repository.
However the best solution would be, if every plain external in every authors subdirectory would be removed there and moved to a central directory with a central Makefile (or SConstruct, if that was chosen).
You first "build" solution was somehow doing exactly this, without actually moving stuff, just by including the files. Maybe it would be time to *actually move* all plain externals into one single, unified directory? Like a big cleanup. The directory should not be called "build" as this is not really an issue about building, maybe it could be called "base-ext" or something like that, to make it clear, that this is the common ground of the whole developer community.
This would be the place for all plain base externals by all authors. It would require, that some externals get removed in their current libraries and moved over to live as single externals in "base-ext" too. Hans' installer then still would be very useful to "catch the rest" of the externals: library-externals like oggplay, flext, Cyclone in Max-compat mode etc. For the base externals he would just call "make" in "base-ext"
One problem with this of course is: How to avoid conflicts when submitting stuff. Should there be a "base-ext" maintainer? The advantage would be, that the externals could get a real common release cycle. Nameclashes with base-exts wouldn't occur anymore. (Every external in a subdirectory, which clashes, would be hijacked and removed by orks.) We could use a namespace like "base" for these externals, and as default "base" would be available without namespace.
I disagree about one big directory, I think that would actually make things more difficult. I think that ideally, all of the code would be organized into libraries/directories with related functionality ("networking", "pan", "synths", etc). Currently, its organized around authors' build systems. But when we use a common build system, then this doesn't need to happen anymore.
externals/Makefile already builds most of the externals files in place, in the authors' directories, and the one Makefile does it for Windows, Mac OS X, and GNU/Linux, no need for separate Makefiles (largely thanks to MinGW). Plus it can (and does) build objects with dependencies (ogg, vorbis, lame, speex, etc.). It should be able to build basically any Pd object written in C without too much hassle. The flext/C++ and Gem stuff currently is separate.
I agree with Thomas Grill in that Pd itself should include just a bare minimum of functionality, stripped down to a Pd kernel of sorts. Pd should be like C or Java, with a small base language, and everything else in libraries, like libc or java.lang.*. Therefore, I think there should be no "base" set of objects.
But it would be good to reorganize things into libraries that cover certain functionality, like I/O or networking or atom conversion. Then we could use externals/build/src-style .c link files to maintain backward compatibility with the old library organization.
.hc
________________________________________________________________________ ____
"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