Re: Options menu is broken on CVS

[Nick Roberts <nickrob@snap.net.nz>]

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