SL Baur wrote: At the top level, the bindist target cycles through the subdirs twice: once making the `autoloads' targets, and once the `bindist' targets, like so: SUBDIRS = libs comm games prog wp os oa mule ... bindist: for dir in $(SUBDIRS); do \ $(MAKE) $(MFLAGS) -C $${dir} autoloads; \ done for dir in $(SUBDIRS); do \ $(MAKE) $(MFLAGS) -C $${dir} bindist; \ done At the next level down, something similar happens for each package, for each of the targets `autoloads' and `bindist': PACKAGES= mule-base \ locale leim edict egg-its skk ... autoloads: for dir in $(PACKAGES); do \ [ -d $${dir} ] && $(MAKE) $(MFLAGS) -C $${dir} autoloads; \ done There were two nasty coincidences. The packages from `edict' to `skk' were missing from the mule directory, and the mule directory was the last entry in the SUBDIRS variable. In the mule directory, the command [ -d $${dir} ] && $(MAKE) etc... returned false from the attempt to make in skk. I presume that the `make autoloads' loop on the SUBDIRS subsequently returns false. Stop. At least, that's what happened. Changing the order of subdirs in the mule Makefile, so that an existing package was the last in the list, allowed the make to proceed. One possibility would be to change the loops in the second level directories to for dir in $(PACKAGES); do \ if [ -d $${dir} ] ; then \ $(MAKE) $(MFLAGS) -C $${dir} autoloads ; \ else true; fi; \ done It might even be a good idea to do the same thing at the top level. I can't see any difficulties with this, but then I am not standing on the shoulders of giants. I have just rebuilt using my re-ordering kludge, but the change above and a similar one at the top level seem to work with `make -n'. -- __ /__ Peter B. West p.west(a)uq.net.au / http://www.uq.net.au/~zzpwest / "Lord, to whom shall we go?"