Re: build system observations

[Dan Nicolaescu]

Adrian Robert <address@hidden> writes:

  > On Aug 5, 2008, at 1:13 AM, Dan Nicolaescu wrote:

  > > #  define GNU_OBJC_CFLAGS -fgnu-runtime -Wno-import -fconstant-
  > > string-class=NSConstantString -DGNUSTEP_BASE_LIBRARY=1 -
  > > DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGSWARN -DGSDIAGNOSE
  > >      This is a new flag, better use autoconf substitions instead of
  > > the preprocessor.
  > 
  > I'm not sure how to do this, but have no objection to someone else
  > making the change if it simplifies things.

In configure.in:
GNU_OBJC_CFLAGS=...
AC_SUBST(GNU_OBJC_CFLAGS)

and use @GNU_OBJC_CFLAGS@ in Makefile.in

  > 
  > > # ifdef C_SWITCH_SYSTEM
  > > # undef C_SWITCH_SYSTEM
  > > # endif
  > >
  > > This sequence has not effect, it can be removed.
  > 
  > This actually comes BEFORE the above definitions, and is to prevent
  > redefinition errors.  Some files under src/s define this, but they do
  > so for X-Windows purposes.  The NS port using GNUstep can be built on
  > these systems and therefore needs to change the switch.

Please look at how src/config.h is generated, it will have /* # undef 
C_SWITCH_SYSTEM */
so I think this never did anything.

  > > lib-src/Makefile.in:
  > >
  > > #if defined(NS_IMPL_COCOA)
  > > /* Build these programs as universal binaries. */
  > > CFLAGS := $(CFLAGS) -universal
  > >
  > >  Is this needed?  It does not seem that the emacs binary itself is
  > > built in the same way.
  > >  There are many ways of adding stuff to CFLAGS, it's cleaner to not
  > > add yet another #ifdef for this.
  > 
  > I took it out.  Anyone attempting to build a binary distribution will
  > need to add -universal to CFLAGS, but only in lib-src.  What is the
  > easiest way to do this?

Add another flag in configure.in?

  > > /* Add mac-fix-env for OS X systems running NS version. */
  > > INSTALLABLES = etags${EXEEXT} ctags${EXEEXT} emacsclient${EXEEXT}
  > > b2m
  > > ${EXEEXT} ebrowse${EXEEXT} mac-fix-env${EXEEXT}
  > >  This can be done more elegantly with and autoconf substitution like
  > > this:
  > >
  > > INSTALLABLES = etags${EXEEXT} ctags${EXEEXT} emacsclient${EXEEXT}
  > > b2m
  > > ${EXEEXT} ebrowse${EXEEXT} @LIB_SRC_EXTRA_INSTALLABLES@
  > >
  > >  and define LIB_SRC_EXTRA_INSTALLABLES with the right value in the
  > > NS_IMPL_COCOA case.
  > 
  > This sounds good (maybe LIB_SRC_ARCHDEP_INSTALLABLES) but I don't

ARCHDEP implies something architecture specific, but that does not seem
to be the case here.

  > trust my autoconf skills enough to attempt this change.

Well, I can do the change, but I can't test it. Unless someone wants
to send me a mac..

  > > src/Makefile.in:
  > >
  > > /* XXX: not working under NS currently due to path shenanigans.. */
  > > #ifndef HAVE_NS
  > >        -./emacs -q -batch -f list-load-path-shadows
  > > #endif
  > >
  > >    This just hides problems and complicates the Makefile.  Better
  > > take the #ifndef out.
  > 
  > I'd welcome help on this one.  I guess the Carbon port didn't need it,
  > but despite NS using identical "path shenanigans" to the Carbon port,
  > it didn't work there.  Not sure what the problem is.

First take it out, and then when people see the problem, someone might
help.  It's just a warning, so it should not harm anyone.

  > > #ifdef HAVE_NS
  > > buffer.o callint.o cmds.o dispnew.o editfns.o fileio.o frame.o \
  > >  fontset.o indent.o insdel.o keyboard.o macros.o minibuf.o msdos.o
  > > process.o \
  > >  scroll.o sysdep.o term.o widget.o window.o xdisp.o xfaces.o
  > > sound.o: nsgui.h
  > >     This can be solved by adding an autoconf variable NSGUI_H and
  > > make all
  > >     these .o file depend on $(NSGUI_H) which is nsgui.h for NS and
  > > nothing everywhere else.
  > >     After that the above #ifdef can probably be removed.
  > 
  > This sounds more complicated than what is there now.  If the goal is
  > to get rid of the Makefile.c system shouldn't this be done all at once
  > and for all GUIs?  (Most of the #ifdef complexity in that file is not
  > due to NS.)

It's better not add to the complexity and do things the right way from
the start instead of placing the burden on someone else in the future.

The way you did it now, it will force rebuilds for people not using NS
when they update and nsgui.h changes.  I personally won't mind, but is
that the case with everyone else?

  > Moved.  Note the following files are placed out of order at the end of
  > the list for some reason:
  > 
  > gtkutil.o
  > dbusbind.o
  > hftctl.o
  > sound.o
  > atimer.o
  > 
  > In the "Lisp proper" section,
  > 
  > lread.o is out of order.
  > 
  > Under "Text properties support", the files are in reverse alphabetical.

Oh, well...


Thanks!

        --dan