Eli Zaretskii writes: > Now, your suggested change simply moves the first instance of xmenu.o > outside the X branch and also outside the HAVE_MENUS condition (and > does nothing for the second instance, btw).
I think the second instance could be removed. > Why is that the right thing? It seems to work for -with/without-x and probably for proprietary systems too. > I think the non-X build on Unix and GNU systems doesn't define > HAVE_MENUS for a reason: without the proper X11 headers and libraries, > xmenu.c simply will not compile. I'm not sure what HAVE_MENUS means but non-X systems clearly have menus (perhaps you've been tricked!). However, xmenu.c _does_ compile without X11 headers and libraries, otherwise you couldn't make a non-X build with it. > Moreover, I have a non-X Emacs built out of CVS of June 11 2005, and > F11->o works there without any problems, although I verified that > xmenu.o was not linked in (in fact, there's no xmenu.o at all there, > since xmenu.c was not compiled). The OP said F10->O didn't work whatever that means. F10->o does work because it doesn't use menu-updating-frames. Try, for example F10->f with your copy, I don't think that will work. > My interim conclusion is that the changes back in 2004 were not the > one that caused the current problem. I think you are wrong. > I will dig some more to understand what is the real cause of that, and > describe my findings here. > Meanwhile, I don't think we should apply your suggested changes, since > compiling xmenu.c on a system without X headers and libraries might > fail due to unresolved externals. It solved the OP's problem. I suggest that we do apply it as thats the only way to test it. If it is wrong, I am sure we will hear about it shortly. Nick _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
