Re: Options menu is broken on CVS

[Eli Zaretskii <eliz@gnu.org>]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Thu, 8 Sep 2005 16:24:50 +1200
> Cc: ismail@uludag.org.tr, emacs-devel@gnu.org
> 
>  > > I think this is the right fix.
>  > 
>  > Please describe the reasons why you think this is the right fix.
> 
> menu-updating-buffers is defined in syms_of_xmenu ().  Currently syms_of_xmenu
> is only called in emacs.c if HAVE_MENUS is true.  menu-updating-buffers is
> needed even if Emacs is configured without X (on GNU/Linux at least) but in
> this case HAVE_MENUS is not defined.
> 
> xmenu.c is needed even HAVE_X_WINDOWS is not defined so I've moved it outside
> the conditional requiring it.

Thanks.

However, this is not what I asked; the reasons why symbols defined in
syms_of_xmenu are void unless xmenu.o is linked in are perfectly
clear.  Sorry for not being more clear.

What I meant is to have an explanation why your change solves the same
problem which caused Kim and myself to place XMENU_OBJ in a different
place, without breaking other ports and configurations.  That would
require to understand the original problem, which had something to do
with Carbon.

> Now I've moved it outside #ifdef HAVE_X_WINDOWS you might need to add
> another condition for when w32menu.o is used, I'm not sure. 

That's exactly the breakage I was afraid of.

>  > That change was made for a reason as well: some problem on Carbon.  We
>  > need to understand that problem, to be sure your change will not
>  > reintroduce it.  I hope that the explanations I asked for above will
>  > clarify this (I still didn't have time to re-read those past
>  > discussions and retrace what problems we were trying to fix.)
> 
> I didn't find the discussion that led to this change.  It might have been
> part of a general tidying process.

No, it was to solve a very specific issue with Carbon.  Okay, I will
try to dig into this over the weekend.  Solution for non-X builds will
have to wait until then.