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