Hi Mats, Ar an triú lá déag de mí Iúil, scríobh Mats Lidell: 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 another patch. -- ¿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 XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches