[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Options menu is broken on CVS

From: Eli Zaretskii
Subject: Re: Options menu is broken on CVS
Date: Fri, 09 Sep 2005 14:50:55 +0300

> Date: Thu, 08 Sep 2005 22:33:45 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden
> >  > 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.

The relevant pieces of information are here:


and in the ensuing threads.  In essence, the events unrolled as

  . Kim moved XMENU_OBJ to a different place (I'm not quite sure why,
    but it had something to do with consolidating image support on
    different systems, see Kim's src/ChangeLog entries for

  . This broke the --without-x build on Unix and GNU systems, since
    xmenu.o was not being linked in.  See the first thread above.

  . I fixed this on 2004-03-13 by adding XMENU_OBJ to the non-X
    branch, conditioned on HAVE_MENUS.

  . This broke the Carbon non-X build, since xmenu.o does not compile
    on Carbon.  (See the second thread above.)  The fix was to
    condition xmenu.o inclusion in the non-X case by HAVE_CARBON _not_
    being defined.

The result of all this was that xmenu.o was being linked in both in
the X and in the non-X branches, and in both cases it was conditioned
on HAVE_MENUS being defined and HAVE_CARBON not being defined (because
Carbon uses macmenu.o instead).

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).  Why is that the right
thing?  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.

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).

My interim conclusion is that the changes back in 2004 were not the
one that caused the current problem.  I will dig some more to
understand what is the real cause of that, and describe my findings

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]