Redirected to xemacs-beta.
Background: I submitted a patch to the package makefiles, building on
Jan's "iterate in make, not in sh" improvements.
>>>>> "Jan" == Jan Vroonhof <jan.vroonhof(a)ntlworld.com> writes:
[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.
>> (2) the packages that get made are the intersection of the
>> packages you request and the package directories that exist,
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."