[PD-dev] removing files from externals/build/src

[Hans-Christoph Steiner]

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