Vpath build are now supported; use --srcdir with configure.

For development, it is useful to know how the make scripts
are organized. From an freshly checked out or untarred state
(after running configure) make at the top level does the following:
        (cd cxx; $(MAKE) reset-depend) // clear out any prior dependencies
        (cd cxx; $(MAKE) gen)	// generate source (babel, other tools)
        (cd cxx; $(MAKE) depend)// gen depends if with --enable-developer 
        (cd cxx; $(MAKE) objs)	// build all .o (.lo) files
        (cd cxx; $(MAKE) libs)	// build all .la files and components
        (cd cxx; $(MAKE) bins)	// build executables
        (cd cxx; $(MAKE) cxx-doc) // build doc if not disabled.

Those wishing to optimize can build the objs directory with
gnu parallel build usage should set the environment variable
CCA_PMAKE="-j 2"
before running make at the top. This allows us to selectively
apply parallel gmake options where possible.

Those wishing to rebuild/reinstall without regenerating can
cd cxx/objs; make clean; cd ..; make objs libs bins
cd ../; make install
All our binaries are in objs and drivers.

Now a word on the structure of the makefiles:
All the configure-determined variables are set in the
toplevel and cxx/Make* files that are included in other
makes down the build tree. All the other makes down the
primary build tree have no configure-dependent values.
Please keep it this way. All changes should go in
Makefile.Vars or Makefile.Rules.
These other makes are generated by configure only so that
configure will handle the copying of the makefiles into
the build tree for us.

If while hacking you change a Makefile 
and want to later double-check, run cxx/util/deltamake
to get the diffs.

distclean isn't working at the moment; who cares? do a vpath
build and just blow the object tree away.
