Re: [packages] More makefile improvements

Redirected to xemacs-beta. Background: I submitted a patch to the package makefiles, building on Jan's "iterate in make, not in sh" improvements. [re: package subdir specs in XEMACS_PACKAGES, like "comm/bbdb"] Jan> I just added them all in september :-) I never had them. I thought about doing it that way, but it makes the definitions of *_PACKAGES much more verbose. So I hacked the Makefile. :-) Furthermore, neither the users nor the developers think of the packages that way; note how much of package-compile.el is devoted to finding dependencies (REQUIRES) across categories. I think the categories should be considered a convenience for users in looking things up, not part of the structure of the package system. Jan> I am not sure I like this side-effect.. If I try to install a Jan> package that (really or through some CVS error or whatever) Jan> doesn't exist there should be an error IMO. I don't know if I agree. I had in mind a case where the top-level Makefile simply defaults XEMACS_PACKAGES = $(ALL_XEMACS_PACKAGES), and then users check out only those packages they want. Then the XEMACS_PACKAGES and MULE_PACKAGES variables would be used by people who want to subset the set of packages they have checked out. Eg, Steve Youngs as package honcho would have vc-cc checked out, but NOT in XEMACS_PACKAGES. It would be easy enough to generate informative warnings or errors (rather than subprocesses barfing for non-obvious reasons like [ -d $(*D) ] fails, which is a bug in your current code I suspect -- I know that until I introduced $(filter ...) I got make errors from that) under control of a make variable ON_PKG_VARS_MISMATCH_SUBDIR_CONTENTS which could take values like ERROR, WARN, IGNORE. Jan> If understand correctly, that means that the $(wildcard *) in Jan> this bit Jan> $(filter $(INSTALL_PACKAGES), $(wildcard *)) Jan> replaced by an excplicit list again does it? Requires more Jan> maintanenance but is less prone to silent failures. What do Jan> the others think? Changing my patch from the nested filter to simply PACKAGES := $(filter $(INSTALL_PACKAGES),$(PACKAGE_ORDER)) does what you want, I think. I prefer a configurable, informative warning, so would tend to use the nested filter plus some additional test as suggested above. -- 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."