Ar an triú lá déag de mí Iúil, scríobh Mats Lidell:
Aidan> This is a good and sane change provoked by the packages build
Aidan> failure of
Aidan> I suspect that it will fix the packages build, but I don’t know
Aidan> for sure, because I have to fight with the infrastructure of
Aidan> the autoload-operators.el and the new VM build structure to get
Aidan> the packages to the point of building at all, and I would
Aidan> prefer to do that tomorrow. Either way, it should be a useful
Aidan> thing to apply--there is no need to prevent an XEmacs without
Aidan> X11 support from building Hyperbole.
I don't understand why the patch is needed? What has changed now that
makes it necessary? Hyperbole workes under many different window
systems, not all actively supported now, but that has never stopped it
from beeing byte compiled under one of them!?
I also fail to recreate the same error situation. With the latest
version of xemacs and the packages I get other problems. Problems that
are fixed by this patch: (The problems beeing failure to load term and
jka-comp so I needed to introduce dependency on eterm and os-utils.)
--- working directory: "/src/xemacs/packages/xemacs-packages/hyperbole/"
% cvs diff
cvs server: Diffing .
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/hyperbole/Makefile,v
retrieving revision 1.13
diff -r1.13 Makefile
< sh-script net-utils ecrypto
> sh-script net-utils ecrypto eterm os-utils
cvs server: Diffing kotl
cvs server: Diffing man
Hyperbole is a package that would benefit from beeing lazy in what
packages it requires for byte compiling so I'm not against the idea. I
just can't understand what is going on here. And you seem to be in
hurry hence this quick answer before analysing the problem
furher. Maybe you can even speed the process by enlightening me.
Weirdly enough, I’m in your position too, the packages build fine for me,
not choking on this problem. (Or indeed on the issues that your change
addresses.) But I do see the logic of why Vin’s build is failing--at compile
time, Hyperbole calls #'sm-window-sys-term to work out what window system
support is available. This is incorrect, as far as I’m concerned, because
the window system support available at compile time is orthogonal to that
available at run time.
My change set the window-system variable to 'stream, on noninteractive runs.
This is a mistake, on further consideration, because the window-system
variable is there for GNU compatibility, and under GNU the value of it is
either nil for TTY or noninteractive use, or some platform-specfic symbol
value; 'mac on carbon, for example. I don’t know what they do since they
integrated multi-tty support. Anyway, since this is a compatibility
variable, and since we have our own sane API, it doesn’t make sense to
change its behaviour to conflict with GNU.
So, the problem is that these two incorrect approaches now intersect in a
way that breaks the compile. If #'sm-window-sys-term finds a non-nil value for
window-system, it assumes mouse support, and tries to load mouse-specific
functions at compile time.
I’ve prepared a change to the trunk that doesn’t set window-system to
'stream on noninteractive runs. However, on investigating further, it should
have been set to nil by the code in console.c:select_console_1 anyway. Vin,
could you do a M-x report-emacs-bug from the build that’s failing? I want to
be reasonably sure I’m actually addressing the problem before sending on
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?OB
XEmacs-Patches mailing list