xemacs-review is redundant once we're on xemacs-beta, isn't it. mb> /bin/sh: -c: line 1: syntax error near unexpected token `;' mb> /bin/sh: -c: line 1: `for dir in ; do make mb> STAGING=/project/xemacs/ws/xemacs-packages/../Mule-Packages -C mb> ${dir} install; done' This is a sh-ism-in-Makefile syntax bug. The patch below (actually, the hunks starting with line 49) fix the bug, and may actually do something sensible with the whole process. I never had time to investigate whether this is the right thing. It also has some editorial comments which may or may not be of use to people who actually hack package Makefiles. Index: Makefile =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-packages/Makefile,v retrieving revision 1.15 diff -u -r1.15 Makefile --- Makefile 2000/06/04 10:22:02 1.15 +++ Makefile 2001/01/08 05:52:20 ＠＠ -17,12 +17,15 ＠＠ SUBDIRS = libs comm games prog wp os oa -# Use a Local.rules file to specify what you wish to have installed +# This is evile, isn't it? XEMACS_PACKAGES_BASE := $(shell pwd) - +# This is obnoxious; I don't see why it is necessary. The real problem is +# macro calls, since macro definitions must be available to the byte- +# compiler. Macros that call macros, maybe? all:: all-bytecompile +# Use a Local.rules file to specify what you wish to have installed include Local.rules.mk -include Local.rules ＠＠ -49,14 +52,16 ＠＠ World: distclean install install: all -ifneq ($(MULE_PACKAGES),'') - for dir in $(MULE_PACKAGES); do \ - $(MAKE) STAGING=$(MULE_STAGING) $(MFLAGS) -C $${dir} install; \ - done +ifneq ('$(MULE_PACKAGES)','') + $(MAKE) STAGING=$(MULE_STAGING) PACKAGES="$(MULE_PACKAGES)" \ + $(MFLAGS) -C mule install endif -ifneq ($(XEMACS_PACKAGES),'') - for dir in $(XEMACS_PACKAGES); do \ - $(MAKE) STAGING=$(XEMACS_STAGING) $(MFLAGS) -C $${dir} install; \ +ifneq ('$(XEMACS_PACKAGES)','') + for dir in $(SUBDIRS); do \ + [ "$${dir}" != "mule" ] \ + && $(MAKE) STAGING=$(XEMACS_STAGING) \ + PACKAGES="$(XEMACS_PACKAGES)" $(MFLAGS) \ + -C $${dir} install; \ done endif ＠＠ -77,3 +82,4 ＠＠ for dir in $(SUBDIRS); do \ $(MAKE) $(MFLAGS) -C $${dir} distclean; \ done + -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

SY> Yes, but it wasn't the fault of the Makefile. It _was_ the fault of the Makefile. In a GNU Makefile ifeq(,'') _fails_. The Makefile attempted to check for empty $(MULE_PACKAGES), but it did so incorrectly. My change (edited for clarity) -ifneq ($(MULE_PACKAGES),'') +ifneq ('$(MULE_PACKAGES)','') is _necessary_, it's not just feeding my sense of symmetry. SY> My first thoughts were that maybe a better approach would be SY> to implement some kind of sanity checking of 'Local.rules'. SY> In other words, if 'BUILD_WITHOUT_MULE' = '' produce a fatal SY> error if 'MULE_PACKAGES' is also empty. It currently is designed to do nothing; it's not clear to me that that's not useful. See below. SY> Obviously, the _BEST_ approach would be autoconf. But autoconf would be capable of inducing that "fatal" error. Presumably the default for BUILD_WITHOUT_MULE would be generated by checking for the mule feature in XEmacs, while MULE_PACKAGES would default to `ls mule` more or less. I can easily imagine a Mule-using developer who only builds PSGML, say. BOOM! Sure, you could get autoconf to do more complex checking, but you could do that in the Makefile, too. And that would probably be preferable, in case somebody tried to override just one of those variables on the make command line. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

SY> Fair enough. Would you like to check through the other SY> Package Makefiles (as well as *.rules) for similar problems SY> and submit a patch accordingly? At the moment, I have to decline. If nobody else does it, in a couple of weeks I'll get back to it. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."