I can build bbdb just fine: cd comm/bbdb; make; make bindist It's the comm Makefile that stops as soon as I get the mew error. As I noted in an earlier email, this keeps eicq and zenirc from building, too. Apparently, the mid-level Makefiles do not ignore errors from leaf directories. - vin "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes:

Steve, I'm a little confused. Shouldn't I be able to _build_ bbdb even if I don't have apel _installed_? I was trying to build all the non-mule packages starting from the root of the packages. As I noted in the first email, 'make' in the comm sub-directory aborted after the mew build failed. The only reason I tried to build comm/bbdb directly is because 'make bindist' from the top level did not generate a bbdb tarfile. When I subsequently ran 'cd comm/bbdb; make bindist' that worked. I now see that if I have apel installed I can apparently build all the non-mule packages. IMO, it should be possible to build all the packages without any packages installed, or with only xemacs-base installed. A slightly less-appealing alternative would be to document all the packages which need to be installed in order to build all the packages. - vin Steve Youngs <youngs(a)xemacs.org&gt; writes:

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: This sounds good. I'd only need to add (require 'poe) to one .el wouldn't I, like ./mew/mew/mew.el? -- |---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp&gt; writes: SY> This sounds good. I'd only need to add (require 'poe) to one SY> .el wouldn't I, like ./mew/mew/mew.el? SJT> No, that would depend on what each individual file requires. SJT> Just put it in all of them. OK, done. Will submit patch and commit shortly. -- |---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

mb> Shouldn't the mew people be involved with this discussion? Yes, they should. Not my problem. I only care that the packages look like they work when 22.0 is released. The other Steve is responsible for making sure they work right, and corresponding with external maintainers. SJT> Just put it in all of them. mb> (require)'s should only go into those files that ... require mb> it. Hey, Steve! Looks like you have a volunteer to check which files "require requires". You know, Martin, I said that. The current situation is a show- stopper for Steve. I'm talking about introducing a teeny-tiny bug that only Martin would care about to take care of the show-stopper in a package Steve probably knows little about. So put it on your (still unpublished) "ten year bug list." I suggested it as one release manager to another, not as a developer. SJT> If Lisp only had functions, we would not need to worry about requires SJT> at build time. (We might want to, for error checking etc, but we SJT> wouldn't need to.) The problem is macros. A macro gets evaluated SJT> twice. The first time, its arguments are treated as literals, and a SJT> new sexp is returned. _This sexp is a compile-time constant._ SJT> The problem is that the bytecompiler provides _no_ facility SJT> for lazy evaluation of macros mb> About the only way it could do that is to not byte-compile the mb> code at all. Of course not. You could do JIT compiling and cache the compiled functions, checking for updates. You may not like that on efficiency grounds (I don't, XEmacs is an editor, not a Lisp theory class); but it's feasible. mb> And if you wanted to always use the run-time mb> definition of a macro, you could never expand macros at mb> compile-time anyways. See above. mb> You may as well not have a byte-compiler. And the user does mb> have that option. Or they can write their own JIT byte-compiler. -- 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."