currently there are several parallel build-systems within the externals section of the repository:

• the pd-extended's generalized build system (combination of scripts and make)
• the /externals/build build-system (make)
• the author's own build system (scripts, make, autoconf/automake, scons, pd-extended, ... or any combination of these)

this eventually leads to unmaintained build-systems

how to solve this:

• /externals/build should really only be used for objects that cannot be build otherwise (e.g. libraries that do not provide splitting into single objects)
• a hierarchical build system (for the rest) might keep the responsibility local
  • anyone can use their own buildsystem
  • for every subdirectory that ought to be included into a meta build system (pd-extended), there should be a a special makefile.extended that gets called by the parent makefile.extended and that is responsible for calling the "real" build system
    • a first-stab makefile.extended could be generated from externals/Makefile
    • we just need a small number of conventional targets with clear semantics, e.g. "build", "install", "clean"

a related issue - flags & flexibility:

• when compiling on a local system, the (advanced) user should be able to set some options (e.g. installation directory, local CFLAGS for optimization, etc.) with a minimum of hassle. One way to do this would be to lump these together into a "local configuration" Makefile which respects environment variable overrides (e.g. which use "?=" and "+=" instead of "=" or "\:=")
• individual build systems should be allowed to vary, but at least we could start establishing some conventions about passing such variables around; the "makefile.extended" could expect to have all relevant variables (CFLAGS, EXTENSION, pd_src, ...) already instantiated with sensible values, and could choose to use these (please!) or not, at the discretion of the package maintainer.