syncing Emacs from sources maintained elsewhere

syncing Emacs from sources maintained elsewhere

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1832 bytes --]

To fix some porting problems I'd like to sync some files in the Emacs
trunk from sources maintained elsewhere (e.g., getopt.c, mktime.c).
I used to do this sort of thing by hand, but nowadays it's typically
done automatically by syncing from gnulib.  I've been working with
RMS, Bruno Haible, and Jim Meyering to automate this process for
Emacs's special requirements.  After some iterations we have come up
with a process that seems to work, and RMS suggested that I mention
the topic here.

Four patches are attached.  Here's a brief description of each.

   01-automate-sync-from-gnulib.diff creates the gnulib infrastructure
   without doing anything with it, so Emacs itself is unaffected.
   This part is reused by the later patches.  The patch is 446 lines.

   03-ftoastr-module.diff adds the ftoastr module (107 lines).  This
   fixes a minor off-by-one bug in printing floating point values on
   hosts that do not use IEEE floating point.

   05-mktime-module.diff adds the mktime module (136 lines).  This
   brings mktime.c up-to-date, fixing some bugs with large time stamps
   on 64-bit hosts.

   09-getopt-gnu-module.diff adds the getopt-gnu module (175 lines).
   This brings getopt.c up-to-date, fixing some minor porting issues.

More gnulib modules can be added later, but I thought I'd start with
these three for now, to give people an idea for what's involved once
the infrastructure is there.  Most of patches 03-, 05-, and 09-
consist of ChangeLog entries and removing no-longer-needed lines.

Accompanying these patches are other patches resulting from
automatically regenerating all the files in question, or to remove
no-longer-needed files, or to simplify code in minor ways.  I can
email all this stuff too, if people are interested, although it's
fairly mechanical and boring.

Comments are welcome.


[-- Attachment #2: 01-automate-sync-from-gnulib.diff --]
[-- Type: text/x-patch, Size: 16828 bytes --]

=== modified file 'ChangeLog'
--- ChangeLog	2011-01-07 20:42:11 +0000
+++ ChangeLog	2011-01-08 21:02:38 +0000
@@ -1,3 +1,32 @@
+2011-01-08  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Automate syncing from gnulib.
+	* INSTALL, README: Document new subdirectory 'lib'.
+	* Makefile.in (SUBDIR): Add lib.
+	(SUBDIR_MAKEFILES): Add lib/Makefile.
+	(lib-src, src, TAGS, tags): Depend on lib.
+	(gnulib_srcdir, GNULIB_MODULES, GNULIB_TOOL_FLAGS): New macros.
+	($(gnulib_srcdir)): New rule.
+	(sync-from-gnulib): New rule, which is .PHONY.
+	(lib): New rule, which is like lib-src.
+	(Makefile): Depend on lib/Makefile.in.
+	(AUTOCONF_INPUTS): Depend on aclocal.m4.
+	(ACLOCAL_INPUTS, AUTOMAKE_INPUTS): New macros.
+	($(srcdir)/aclocal.m4, $(srcdir)/lib/Makefile.in): New rules.
+	(am--refresh): New rule, to pacify Automake.
+	(mostlyclean, clean, distclean, bootstrap-clean, maintainer-clean):
+	Clean lib, too.
+	(top_maintainer_clean): New macro, to remove gnulib-tool and Automake
+	droppings.
+	(maintainer-clean, extraclean): Use it.
+	* configure.in: Initialize for automake and gnulib, by invoking
+	AM_INIT_AUTOMAKE, AM_PROG_CC_C_O, gl_EARLY, and gl_INIT.  Output
+	lib/Makefile, too.  Use automake to build gnulib, as gnulib works
+	more conveniently with automake.
+	* lib/Makefile.am: New file.
+	* make-dist: Also put into the distribution aclocal.m4,
+	compile, depcomp, missing, and the files under lib/.
+
 2011-01-07  Paul Eggert  <eggert@cs.ucla.edu>
 
 	* install-sh, mkinstalldirs, move-if-change: Update from master

=== modified file 'INSTALL'
--- INSTALL	2010-12-16 23:30:57 +0000
+++ INSTALL	2011-01-08 21:02:38 +0000
@@ -675,12 +675,15 @@
 `./src/epaths.h' from the template file `./src/epaths.in', changing
 the paths to the values specified in `./Makefile'.
 
-2) Go to directory `./lib-src' and run `make'.  This creates
+2) Go to directory `./lib' and run `make'.  This creates include files
+and libraries used in later steps.
+
+3) Go to directory `./lib-src' and run `make'.  This creates
 executables named `etags', `make-docfile', and others.
 
-3) Go to directory `./src' and run `make'.  This refers to files in
-the `./lisp' and `./lib-src' subdirectories using names `../lisp' and
-`../lib-src'.
+4) Go to directory `./src' and run `make'.  This refers to files in
+the `./lisp', `./lib', and `./lib-src' subdirectories using names
+`../lisp', `../lib', and `../lib-src'.
 
 This creates a file `./src/emacs' which is the runnable Emacs,
 which has another name that contains a version number.

=== modified file 'Makefile.in'
--- Makefile.in	2011-01-05 07:10:47 +0000
+++ Makefile.in	2011-01-08 21:02:38 +0000
@@ -264,10 +264,10 @@
 # Actually, we now include `lisp' as well, since the compiled files
 # are not included any more in case of bootstrap or in case Emacs was
 # checked out from a VCS.
-SUBDIR = lib-src src lisp
+SUBDIR = lib lib-src src lisp
 
 # The subdir makefiles created by config.status.
-SUBDIR_MAKEFILES = lib-src/Makefile doc/emacs/Makefile doc/misc/Makefile doc/lispref/Makefile doc/lispintro/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile leim/Makefile lisp/Makefile
+SUBDIR_MAKEFILES = lib/Makefile lib-src/Makefile doc/emacs/Makefile doc/misc/Makefile doc/lispref/Makefile doc/lispintro/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile leim/Makefile lisp/Makefile
 
 # Subdirectories to install, and where they'll go.
 # lib-src's makefile knows how to install it, so we don't do that here.
@@ -313,6 +313,8 @@
 	  CC='${CC}' CFLAGS='${CFLAGS}' CPPFLAGS='${CPPFLAGS}' \
 	  LDFLAGS='${LDFLAGS}' MAKE='${MAKE}')
 
+lib-src src: lib
+
 src:	lib-src FRC
 
 .RECURSIVE: ${SUBDIR} leim
@@ -320,8 +322,32 @@
 # We need to build `emacs' in `src' to compile the *.elc files in `lisp'.
 lisp: src
 
+# Maintainers can put a copy of gnulib into $(gnulib_srcdir).
+gnulib_srcdir = ../gnulib
+$(gnulib_srcdir):
+	git clone git://git.savannah.gnu.org/gnulib.git $@
+
+# Update modules from gnulib, for maintainers, who should have it in
+# $(gnulib_srcdir) (relative to $(srcdir) and should have build tools
+# as per $(gnulib_srcdir)/DEPENDENCIES.
+GNULIB_MODULES = dummy # Just a dummy for now, to establish the mechanism.
+GNULIB_TOOL_FLAGS = \
+ --import --no-changelog --no-vc-files --makefile-name=gnulib.mk
+sync-from-gnulib: $(gnulib_srcdir)
+	cd $(srcdir) && \
+	  $(gnulib_srcdir)/gnulib-tool $(GNULIB_TOOL_FLAGS) $(GNULIB_MODULES)
+	cp $(gnulib_srcdir)/build-aux/texinfo.tex $(srcdir)/doc/misc
+	cp \
+	  $(gnulib_srcdir)/build-aux/config.sub \
+	  $(gnulib_srcdir)/build-aux/config.guess \
+	  $(gnulib_srcdir)/build-aux/install-sh \
+	  $(gnulib_srcdir)/build-aux/mkinstalldirs \
+	  $(gnulib_srcdir)/build-aux/move-if-change \
+	  $(srcdir)
+.PHONY: sync-from-gnulib
+
 # These targets should be "${SUBDIR} without `src'".
-lib-src lisp: Makefile FRC
+lib lib-src lisp: Makefile FRC
 	cd $@; $(MAKE) all $(MFLAGS)                           \
 	  CC='${CC}' CFLAGS='${CFLAGS}' CPPFLAGS='${CPPFLAGS}' \
 	  LDFLAGS='${LDFLAGS}' MAKE='${MAKE}'
@@ -360,6 +386,7 @@
 Makefile: config.status $(srcdir)/src/config.in \
           $(srcdir)/Makefile.in \
           $(srcdir)/src/Makefile.in \
+          $(srcdir)/lib/Makefile.in \
           $(srcdir)/lib-src/Makefile.in \
           $(srcdir)/doc/emacs/Makefile.in \
           $(srcdir)/doc/misc/Makefile.in \
@@ -374,11 +401,20 @@
 config.status: ${srcdir}/configure ${srcdir}/lisp/version.el
 	./config.status --recheck
 
-AUTOCONF_INPUTS = @MAINT@ $(srcdir)/configure.in $(srcdir)/m4/getopt.m4
+AUTOCONF_INPUTS = @MAINT@ $(srcdir)/configure.in $(srcdir)/m4/getopt.m4 $(srcdir)/aclocal.m4
 
 $(srcdir)/configure: $(AUTOCONF_INPUTS)
 	cd ${srcdir} && autoconf
 
+ACLOCAL_INPUTS = @MAINT@ $(srcdir)/m4/gnulib-comp.m4 
+$(srcdir)/aclocal.m4: $(ACLOCAL_INPUTS)
+	cd $(srcdir) && aclocal -I m4
+
+AUTOMAKE_INPUTS = @MAINT@ $(srcdir)/aclocal.m4 $(srcdir)/lib/Makefile.am
+$(srcdir)/lib/Makefile.in: $(AUTOMAKE_INPUTS)
+	cd $(srcdir) && automake --gnu -a -c lib/Makefile
+am--refresh:
+
 $(srcdir)/src/config.in: $(srcdir)/src/stamp-h.in
 	@ # Usually, there's no need to rebuild src/config.in just
 	@ # because stamp-h.in has changed (since building stamp-h.in
@@ -710,6 +746,7 @@
 	(cd src;      $(MAKE) $(MFLAGS) mostlyclean)
 	(cd oldXMenu; $(MAKE) $(MFLAGS) mostlyclean)
 	(cd lwlib;    $(MAKE) $(MFLAGS) mostlyclean)
+	(cd lib;      $(MAKE) $(MFLAGS) mostlyclean)
 	(cd lib-src;  $(MAKE) $(MFLAGS) mostlyclean)
 	-(cd doc/emacs &&   $(MAKE) $(MFLAGS) mostlyclean)
 	-(cd doc/misc &&   $(MAKE) $(MFLAGS) mostlyclean)
@@ -729,6 +766,7 @@
 	(cd src;      $(MAKE) $(MFLAGS) clean)
 	(cd oldXMenu; $(MAKE) $(MFLAGS) clean)
 	(cd lwlib;    $(MAKE) $(MFLAGS) clean)
+	(cd lib;      $(MAKE) $(MFLAGS) clean)
 	(cd lib-src;  $(MAKE) $(MFLAGS) clean)
 	-(cd doc/emacs &&   $(MAKE) $(MFLAGS) clean)
 	-(cd doc/misc &&   $(MAKE) $(MFLAGS) clean)
@@ -753,6 +791,7 @@
 	(cd src;      $(MAKE) $(MFLAGS) distclean)
 	(cd oldXMenu; $(MAKE) $(MFLAGS) distclean)
 	(cd lwlib;    $(MAKE) $(MFLAGS) distclean)
+	(cd lib;      $(MAKE) $(MFLAGS) distclean)
 	(cd lib-src;  $(MAKE) $(MFLAGS) distclean)
 	(cd doc/emacs &&    $(MAKE) $(MFLAGS) distclean)
 	(cd doc/misc &&    $(MAKE) $(MFLAGS) distclean)
@@ -769,6 +808,7 @@
 	(cd src;      $(MAKE) $(MFLAGS) bootstrap-clean)
 	(cd oldXMenu; $(MAKE) $(MFLAGS) maintainer-clean)
 	(cd lwlib;    $(MAKE) $(MFLAGS) maintainer-clean)
+	(cd lib;      $(MAKE) $(MFLAGS) maintainer-clean)
 	(cd lib-src;  $(MAKE) $(MFLAGS) maintainer-clean)
 	-(cd doc/emacs &&   $(MAKE) $(MFLAGS) maintainer-clean)
 	-(cd doc/misc &&   $(MAKE) $(MFLAGS) maintainer-clean)
@@ -789,10 +829,15 @@
 ###      Makefile.  More generally, `make maintainer-clean' should not delete
 ###      anything that needs to exist in order to run `configure' and then
 ###      begin to build the program.
+top_maintainer_clean=\
+	${top_distclean}; \
+	rm -fr autom4te.cache; \
+	rm -f aclocal.m4 lib/gnulib.mk m4/gnulib-cache.m4
 maintainer-clean: bootstrap-clean FRC
 	(cd src;      $(MAKE) $(MFLAGS) maintainer-clean)
+	(cd lib;      $(MAKE) $(MFLAGS) maintainer-clean)
 	(cd lisp;     $(MAKE) $(MFLAGS) maintainer-clean)
-	${top_distclean}
+	${top_maintainer_clean}
 
 ### This doesn't actually appear in the coding standards, but Karl
 ### says GCC supports it, and that's where the configuration part of
@@ -800,13 +845,13 @@
 ### it deletes backup and autosave files too.
 extraclean:
 	for i in ${SUBDIR} leim; do (cd $$i; $(MAKE) $(MFLAGS) extraclean); done
-	${top_distclean}
+	${top_maintainer_clean}
 	-rm -f config-tmp-*
 	-rm -f *~ \#*
 
 # The src subdir knows how to do the right thing
 # even when the build directory and source dir are different.
-TAGS tags: lib-src src
+TAGS tags: lib lib-src src
 	cd src; $(MAKE) tags
 
 check:

=== modified file 'README'
--- README	2010-12-16 23:30:57 +0000
+++ README	2011-01-08 21:02:38 +0000
@@ -63,6 +63,7 @@
 `leim'      holds the library of Emacs input methods, Lisp code and
             auxiliary data files required to type international characters
             which can't be directly produced by your keyboard.
+`lib'       holds source code for libraries used by Emacs and its utilities
 `lib-src'   holds the source code for some utility programs for use by or
             with Emacs, like movemail and etags.
 `etc'       holds miscellaneous architecture-independent data files Emacs

=== modified file 'configure.in'
--- configure.in	2011-01-05 13:09:07 +0000
+++ configure.in	2011-01-08 21:02:38 +0000
@@ -27,6 +27,7 @@
 AC_INIT(emacs, 24.0.50)
 AC_CONFIG_HEADER(src/config.h:src/config.in)
 AC_CONFIG_SRCDIR(src/lisp.h)
+AM_INIT_AUTOMAKE
 
 dnl Support for --program-prefix, --program-suffix and
 dnl --program-transform-name options
@@ -638,6 +639,10 @@
 
 dnl Sets GCC=yes if using gcc.
 AC_PROG_CC
+AM_PROG_CC_C_O
+
+# Initialize gnulib right after verifying that the C compiler works.
+gl_EARLY
 
 # On Suns, sometimes $CPP names a directory.
 if test -n "$CPP" && test -d "$CPP"; then
@@ -2668,6 +2673,9 @@
 
 AC_FUNC_GETPGRP
 
+# Configure gnulib.
+gl_INIT
+
 AC_FUNC_STRFTIME
 
 # UNIX98 PTYs.
@@ -3747,7 +3755,7 @@
 dnl to run `make prefix=/some/where/else' and override the values set
 dnl by configure.  This also explains the `move-if-change' test and
 dnl the use of force in the `epaths-force' rule in Makefile.in.
-AC_OUTPUT(Makefile lib-src/Makefile oldXMenu/Makefile \
+AC_OUTPUT(Makefile lib/Makefile lib-src/Makefile oldXMenu/Makefile \
 	doc/emacs/Makefile doc/misc/Makefile doc/lispintro/Makefile \
 	doc/lispref/Makefile src/Makefile \
 	lwlib/Makefile lisp/Makefile leim/Makefile, [

=== added directory 'lib'
=== modified file 'lib-src/ChangeLog'
--- lib-src/ChangeLog	2011-01-08 19:03:31 +0000
+++ lib-src/ChangeLog	2011-01-08 21:02:38 +0000
@@ -1,5 +1,15 @@
 2011-01-08  Paul Eggert  <eggert@cs.ucla.edu>
 
+	Automate syncing from gnulib.
+	* Makefile.in (EXE_FILES): New macro.
+	(BASE_CFLAGS): Add -I../lib and -I${srcdir}/../lib,
+	for gnulib's .h files.
+	(LOADLIBES): Add ../lib/libgnu.a.
+	($(EXE_FILES)): Depend on ../lib/libgnu.a.
+	(../lib/libgnu.a): New rule.
+
+2011-01-08  Paul Eggert  <eggert@cs.ucla.edu>
+
 	* Makefile.in (EXECUTABLES): Remove; macro unused since 1993.
 
 2011-01-08  Glenn Morris  <rgm@gnu.org>

=== modified file 'lib-src/Makefile.in'
--- lib-src/Makefile.in	2011-01-08 19:03:31 +0000
+++ lib-src/Makefile.in	2011-01-08 21:02:38 +0000
@@ -128,6 +128,9 @@
 SCRIPTS= rcs2log vcdiff
 STAMP_SCRIPTS= stamp-rcs2log stamp-vcdiff
 
+# All files that are created by the linker, i.e., whose names end in ${EXEEXT}.
+EXE_FILES = ${INSTALLABLES} ${UTILITIES} ${DONT_INSTALL}
+
 # Specify additional -D flags for movemail. Options:
 # -DMAIL_USE_FLOCK or -DMAIL_USE_LOCKF (use flock or lockf for file locking).
 # See the comments about locking in movemail.c.  Normally the values
@@ -166,13 +169,15 @@
 # defined before they know they can take advantage of the information
 # in ../src/config.h.
 BASE_CFLAGS = $(C_SWITCH_SYSTEM) $(C_SWITCH_MACHINE) ${C_WARNINGS_SWITCH} \
-	      -DHAVE_CONFIG_H -I. -I../src -I${srcdir} -I${srcdir}/../src
+	      -DHAVE_CONFIG_H -I. -I../src -I../lib \
+	      -I${srcdir} -I${srcdir}/../src -I${srcdir}/../lib
 
 ALL_CFLAGS = ${BASE_CFLAGS} ${PROFILING_CFLAGS} ${LDFLAGS} ${CPPFLAGS} ${CFLAGS}
 LINK_CFLAGS = ${BASE_CFLAGS} ${LDFLAGS} ${CFLAGS}
 CPP_CFLAGS = ${BASE_CFLAGS} ${PROFILING_CFLAGS} ${CPPFLAGS} ${CFLAGS}
 
-LOADLIBES=$(LIBS_SYSTEM)
+LOADLIBES = ../lib/libgnu.a $(LIBS_SYSTEM)
+$(EXE_FILES): ../lib/libgnu.a
 
 ## This is the default compilation command.
 ## But we should never rely on it, because some make version failed to
@@ -320,6 +325,9 @@
 getopt1.o: ${srcdir}/getopt1.c $(GETOPT_H)
 	${CC} -c ${CPP_CFLAGS} ${srcdir}/getopt1.c
 
+../lib/libgnu.a: ../src/config.h
+	cd ../lib && $(MAKE) libgnu.a
+
 REGEXPOBJ = regex.o
 REGEXPDEPS = $(REGEXPOBJ) $(srcdir)/../src/regex.h
 

=== added file 'lib/Makefile.am'
--- lib/Makefile.am	1970-01-01 00:00:00 +0000
+++ lib/Makefile.am	2011-01-08 21:02:38 +0000
@@ -0,0 +1,8 @@
+BUILT_SOURCES =
+EXTRA_DIST =
+MOSTLYCLEANFILES =
+noinst_LIBRARIES =
+
+DEFAULT_INCLUDES = -I. -I../src -I$(top_srcdir)/src
+
+include gnulib.mk

=== modified file 'make-dist'
--- make-dist	2010-12-16 23:30:57 +0000
+++ make-dist	2011-01-08 21:02:38 +0000
@@ -286,12 +286,14 @@
 ln ChangeLog Makefile.in configure configure.in ${tempdir}
 ln config.bat make-dist update-subdirs vpath.sed .dir-locals.el ${tempdir}
 ln mkinstalldirs config.sub config.guess install-sh ${tempdir}
+ln aclocal.m4 ${tempdir}
+ln compile depcomp missing ${tempdir}
 
 echo "Creating subdirectories"
 for subdir in site-lisp \
 	      leim leim/CXTERM-DIC leim/MISC-DIC \
 	      leim/SKK-DIC leim/ja-dic leim/quail \
-	      src src/m src/s src/bitmaps lib-src oldXMenu lwlib \
+	      src src/m src/s src/bitmaps lib lib-src oldXMenu lwlib \
 	      nt nt/inc nt/inc/sys nt/inc/arpa nt/inc/netinet nt/icons \
 	      `find etc lisp -type d` \
 	      doc doc/emacs doc/misc doc/man doc/lispref doc/lispintro \
@@ -368,6 +370,14 @@
 (cd src/s
  ln README [a-zA-Z0-9]*.h ../../${tempdir}/src/s)
 
+echo "Making links to \`lib'"
+(build_aux_h=`(ls *.h)`
+ cd lib
+ ln [a-zA-Z]*.[ch] ../${tempdir}/lib
+ ln gnulib.mk Makefile.am Makefile.in ../${tempdir}/lib
+ cd ../${tempdir}/lib
+ rm -f `(echo "$build_aux_h"; ls *.in.h) | sed '/[*]/d; s/.in.h$/.h/'`)
+
 echo "Making links to \`lib-src'"
 (cd lib-src
  ln [a-zA-Z]*.[ch] ../${tempdir}/lib-src
@@ -477,7 +487,7 @@
 ### It would be nice if they could all be symlinks to top-level copy, but
 ### you're not supposed to have any symlinks in distribution tar files.
 echo "Making sure copying notices are all copies of \`COPYING'"
-for subdir in . etc info leim lib-src lisp lwlib msdos nt src; do
+for subdir in . etc info leim lib lib-src lisp lwlib msdos nt src; do
   rm -f ${tempdir}/${subdir}/COPYING
   cp COPYING ${tempdir}/${subdir}
 done

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2011-01-08 13:32:31 +0000
+++ src/ChangeLog	2011-01-08 21:02:38 +0000
@@ -1,3 +1,11 @@
+2011-01-08  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Automate syncing from gnulib.
+	* Makefile.in (lib): New macro.
+	(ALL_CFLAGS): Add -I$(lib) -I$(srcdir)/../lib.
+	($(lib)/libgnu.a): New rule.
+	(temacs$(EXEEXT)): Also link $(lib)/libgnu.a.
+
 2011-01-08  Andreas Schwab  <schwab@linux-m68k.org>
 
 	* fns.c (Fyes_or_no_p): Add usage.
@@ -29483,4 +29491,3 @@
 
   You should have received a copy of the GNU General Public License
   along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
-

=== modified file 'src/Makefile.in'
--- src/Makefile.in	2011-01-08 02:41:14 +0000
+++ src/Makefile.in	2011-01-08 21:02:38 +0000
@@ -47,6 +47,7 @@
 LIBOBJS = @LIBOBJS@
 
 lispsource = $(srcdir)/../lisp
+lib = ../lib
 libsrc = ../lib-src
 etc = ../etc
 oldXMenudir = ../oldXMenu
@@ -320,6 +321,7 @@
 ##
 ## FIXME? MYCPPFLAGS only referenced in etc/DEBUG.
 ALL_CFLAGS=-Demacs -DHAVE_CONFIG_H $(MYCPPFLAGS) -I. -I$(srcdir) \
+  -I$(lib) -I$(srcdir)/../lib \
   $(C_SWITCH_MACHINE) $(C_SWITCH_SYSTEM) $(C_SWITCH_X_SITE) \
   $(C_SWITCH_X_SYSTEM) $(CFLAGS_SOUND) $(RSVG_CFLAGS) $(IMAGEMAGICK_CFLAGS) \
   $(LIBXML2_CFLAGS) $(DBUS_CFLAGS) \
@@ -644,10 +646,12 @@
 buildobj.h: Makefile
 	echo "#define BUILDOBJ \"$(obj) $(otherobj) " "\"" > buildobj.h
 
+$(lib)/libgnu.a: $(config_h)
+	cd $(lib) && $(MAKE) libgnu.a
 
-temacs$(EXEEXT): $(START_FILES) stamp-oldxmenu $(obj) $(otherobj)
+temacs$(EXEEXT): $(START_FILES) stamp-oldxmenu $(obj) $(otherobj) $(lib)/libgnu.a
 	$(CC) $(LD_FIRSTFLAG) $(ALL_CFLAGS) $(TEMACS_LDFLAGS) $(TEMACS_LDFLAGS2) \
-	  -o temacs $(START_FILES) $(obj) $(otherobj) $(LIBES)
+	  -o temacs $(START_FILES) $(obj) $(otherobj) $(lib)/libgnu.a $(LIBES)
 
 ## The following oldxmenu-related rules are only (possibly) used if
 ## HAVE_X11 && !USE_GTK, but there is no harm in always defining them


[-- Attachment #3: 03-ftoastr-module.diff --]
[-- Type: text/x-patch, Size: 3434 bytes --]

=== modified file 'ChangeLog'
--- ChangeLog	2011-01-08 21:19:44 +0000
+++ ChangeLog	2011-01-09 01:18:39 +0000
@@ -1,3 +1,8 @@
+2011-01-09  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Use gnulib ftoastr module.
+	* Makefile.in (GNULIB_MODULES): Add ftoastr.  Remove dummy.
+
 2011-01-08  Paul Eggert  <eggert@cs.ucla.edu>
 
 	Regenerate.

=== modified file 'Makefile.in'
--- Makefile.in	2011-01-08 21:02:38 +0000
+++ Makefile.in	2011-01-09 01:18:39 +0000
@@ -330,7 +330,7 @@
 # Update modules from gnulib, for maintainers, who should have it in
 # $(gnulib_srcdir) (relative to $(srcdir) and should have build tools
 # as per $(gnulib_srcdir)/DEPENDENCIES.
-GNULIB_MODULES = dummy # Just a dummy for now, to establish the mechanism.
+GNULIB_MODULES = ftoastr
 GNULIB_TOOL_FLAGS = \
  --import --no-changelog --no-vc-files --makefile-name=gnulib.mk
 sync-from-gnulib: $(gnulib_srcdir)

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2011-01-08 21:02:38 +0000
+++ src/ChangeLog	2011-01-09 01:18:39 +0000
@@ -1,3 +1,12 @@
+2011-01-09  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Use gnulib's ftoastr module.
+	* print.c: Include ftoastr.h.
+	(FLT_RADIX, DBL_MANT_DIG, DBL_DIG, DBL_MIN, DOUBLE_DIGITS_BOUND):
+	Remove; no longer needed.
+	(float_to_string): Use dtoastr rather than rolling our own code,
+	which had an off-by-one bug on non-IEEE hosts.
+
 2011-01-08  Paul Eggert  <eggert@cs.ucla.edu>
 
 	Automate syncing from gnulib.

=== modified file 'src/print.c'
--- src/print.c	2010-12-27 17:29:38 +0000
+++ src/print.c	2011-01-09 01:18:39 +0000
@@ -50,36 +50,12 @@
 #if STDC_HEADERS
 #include <float.h>
 #endif
+#include <ftoastr.h>
 
 /* Default to values appropriate for IEEE floating point.  */
-#ifndef FLT_RADIX
-#define FLT_RADIX 2
-#endif
-#ifndef DBL_MANT_DIG
-#define DBL_MANT_DIG 53
-#endif
 #ifndef DBL_DIG
 #define DBL_DIG 15
 #endif
-#ifndef DBL_MIN
-#define DBL_MIN 2.2250738585072014e-308
-#endif
-
-#ifdef DBL_MIN_REPLACEMENT
-#undef DBL_MIN
-#define DBL_MIN DBL_MIN_REPLACEMENT
-#endif
-
-/* Define DOUBLE_DIGITS_BOUND, an upper bound on the number of decimal digits
-   needed to express a float without losing information.
-   The general-case formula is valid for the usual case, IEEE floating point,
-   but many compilers can't optimize the formula to an integer constant,
-   so make a special case for it.  */
-#if FLT_RADIX == 2 && DBL_MANT_DIG == 53
-#define DOUBLE_DIGITS_BOUND 17 /* IEEE floating point */
-#else
-#define DOUBLE_DIGITS_BOUND ((int) ceil (log10 (pow (FLT_RADIX, DBL_MANT_DIG))))
-#endif
 
 /* Avoid actual stack overflow in print.  */
 int print_depth;
@@ -1125,19 +1101,8 @@
     {
       /* Generate the fewest number of digits that represent the
 	 floating point value without losing information.
-	 The following method is simple but a bit slow.
-	 For ideas about speeding things up, please see:
-
-	 Guy L Steele Jr & Jon L White, How to print floating-point numbers
-	 accurately.  SIGPLAN notices 25, 6 (June 1990), 112-126.
-
-	 Robert G Burger & R Kent Dybvig, Printing floating point numbers
-	 quickly and accurately, SIGPLAN notices 31, 5 (May 1996), 108-116.  */
-
-      width = fabs (data) < DBL_MIN ? 1 : DBL_DIG;
-      do
-	sprintf (buf, "%.*g", width, data);
-      while (width++ < DOUBLE_DIGITS_BOUND && atof (buf) != data);
+         The 350 is by convention, e.g., this file's pigbuf.  */
+      dtoastr (buf, 350, 0, 0, data);
     }
   else			/* oink oink */
     {


[-- Attachment #4: 05-mktime-module.diff --]
[-- Type: text/x-patch, Size: 5000 bytes --]

=== modified file 'ChangeLog'
--- ChangeLog	2011-01-09 01:18:39 +0000
+++ ChangeLog	2011-01-09 04:31:19 +0000
@@ -1,6 +1,18 @@
 2011-01-09  Paul Eggert  <eggert@cs.ucla.edu>
 
-	Use gnulib ftoastr module.
+	Use gnulib's mktime module.
+	* Makefile.in (GNULIB_MODULES): Add mktime.
+	* configure.in: Remove code no longer needed, as gnulib now does it.
+	(AC_CHECK_FUNCS): Remove mktime.
+	(AC_FUNC_MKTIME, BROKEN_MKTIME): Remove.
+	(__restrict): Remove, as this now gets in the way of the C99
+	support for 'restrict' pulled in by the gnulib mktime module.
+	Code should now use 'restrict' and not '__restrict".
+	(mktime): Remove.
+	* make-dist: Put gnulib-generated files arg-nonnull.h, c++defs.h,
+	and warn-on-use.h into the distribution.
+	
+	Use gnulib's ftoastr module.
 	* Makefile.in (GNULIB_MODULES): Add ftoastr.  Remove dummy.
 
 2011-01-08  Paul Eggert  <eggert@cs.ucla.edu>

=== modified file 'Makefile.in'
--- Makefile.in	2011-01-09 01:18:39 +0000
+++ Makefile.in	2011-01-09 04:31:19 +0000
@@ -330,7 +330,7 @@
 # Update modules from gnulib, for maintainers, who should have it in
 # $(gnulib_srcdir) (relative to $(srcdir) and should have build tools
 # as per $(gnulib_srcdir)/DEPENDENCIES.
-GNULIB_MODULES = ftoastr
+GNULIB_MODULES = ftoastr mktime
 GNULIB_TOOL_FLAGS = \
  --import --no-changelog --no-vc-files --makefile-name=gnulib.mk
 sync-from-gnulib: $(gnulib_srcdir)

=== modified file 'configure.in'
--- configure.in	2011-01-08 21:02:38 +0000
+++ configure.in	2011-01-09 04:31:19 +0000
@@ -2632,7 +2632,7 @@
 AC_CHECK_FUNCS(gethostname getdomainname dup2 \
 rename closedir mkdir rmdir sysinfo getrusage get_current_dir_name \
 random lrand48 logb frexp fmod rint cbrt ftime setsid \
-strerror fpathconf select mktime euidaccess getpagesize tzset setlocale \
+strerror fpathconf select euidaccess getpagesize tzset setlocale \
 utimes getrlimit setrlimit setpgid getcwd getwd shutdown getaddrinfo \
 __fpending mblen mbrlen mbsinit strsignal setitimer ualarm strchr strrchr \
 sendto recvfrom getsockopt setsockopt getsockname getpeername \
@@ -2653,11 +2653,6 @@
 
 AC_CHECK_HEADERS(sys/un.h)
 
-AC_FUNC_MKTIME
-if test "$ac_cv_func_working_mktime" = no; then
-  AC_DEFINE(BROKEN_MKTIME, 1, [Define to 1 if the mktime function is broken.])
-fi
-
 AC_FUNC_GETLOADAVG
 
 AC_FUNC_FSEEKO
@@ -3039,24 +3034,6 @@
 
 AC_TYPE_MBSTATE_T
 
-dnl Restrict could probably be used effectively other than in regex.c.
-AC_CACHE_CHECK([for C restrict keyword], emacs_cv_c_restrict,
-  [AC_TRY_COMPILE([void fred (int *restrict x);], [],
-                  emacs_cv_c_restrict=yes,
-                  [AC_TRY_COMPILE([void fred (int *__restrict x);], [],
-                                  emacs_cv_c_restrict=__restrict,
-				  emacs_cv_c_restrict=no)])])
-case "$emacs_cv_c_restrict" in
-  yes) emacs_restrict=restrict;;
-  no) emacs_restrict="";;
-  *) emacs_restrict="$emacs_cv_c_restrict";;
-esac
-if test "$emacs_restrict" != __restrict; then
-  AC_DEFINE_UNQUOTED(__restrict, $emacs_restrict,
-    [Define to compiler's equivalent of C99 restrict keyword.
-     Don't define if equivalent is `__restrict'.])
-fi
-
 AC_CACHE_CHECK([for C restricted array declarations], emacs_cv_c_restrict_arr,
   [AC_TRY_COMPILE([void fred (int x[__restrict]);], [],
                   emacs_cv_c_restrict_arr=yes, emacs_cv_c_restrict_arr=no)])
@@ -3546,11 +3523,6 @@
 #endif
 #endif
 
-/* Avoid link-time collision with system mktime if we will use our own.  */
-#if ! HAVE_MKTIME || BROKEN_MKTIME
-#define mktime emacs_mktime
-#endif
-
 #define my_strftime nstrftime	/* for strftime.c */
 
 /* These default definitions are good for almost all machines.

=== modified file 'make-dist'
--- make-dist	2011-01-08 21:02:38 +0000
+++ make-dist	2011-01-09 04:31:19 +0000
@@ -288,6 +288,7 @@
 ln mkinstalldirs config.sub config.guess install-sh ${tempdir}
 ln aclocal.m4 ${tempdir}
 ln compile depcomp missing ${tempdir}
+ln arg-nonnull.h c++defs.h warn-on-use.h ${tempdir}
 
 echo "Creating subdirectories"
 for subdir in site-lisp \

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2011-01-09 01:18:39 +0000
+++ src/ChangeLog	2011-01-09 04:31:19 +0000
@@ -1,5 +1,8 @@
 2011-01-09  Paul Eggert  <eggert@cs.ucla.edu>
 
+	Use gnulib's mktime module.
+	* deps.mk (mktime.o): Remove rule.
+
 	Use gnulib's ftoastr module.
 	* print.c: Include ftoastr.h.
 	(FLT_RADIX, DBL_MANT_DIG, DBL_DIG, DBL_MIN, DOUBLE_DIGITS_BOUND):

=== modified file 'src/deps.mk'
--- src/deps.mk	2010-09-18 14:09:40 +0000
+++ src/deps.mk	2011-01-09 04:31:19 +0000
@@ -138,7 +138,6 @@
 minibuf.o: minibuf.c syntax.h frame.h window.h keyboard.h systime.h \
    buffer.h commands.h character.h msdos.h $(INTERVALS_H) keymap.h \
    termhooks.h lisp.h $(config_h) coding.h
-mktime.o: mktime.c $(config_h)
 msdos.o: msdos.c msdos.h dosfns.h systime.h termhooks.h dispextern.h frame.h \
    termopts.h termchar.h character.h coding.h ccl.h disptab.h window.h \
    keyboard.h $(INTERVALS_H) buffer.h commands.h blockinput.h atimer.h \


[-- Attachment #5: 09-getopt-gnu-module.diff --]
[-- Type: text/x-patch, Size: 6223 bytes --]

=== modified file 'ChangeLog'
--- ChangeLog	2011-01-09 06:57:07 +0000
+++ ChangeLog	2011-01-09 07:29:26 +0000
@@ -1,5 +1,13 @@
 2011-01-09  Paul Eggert  <eggert@cs.ucla.edu>
 
+	Use gnulib's getopt-gnu module.
+	* Makefile.in (GNULIB_MODULES): Add getopt-gnu.
+	(AUTOCONF_INPUTS): Remove getopt.m4; aclocal.m4 is a good-enough
+	representative of the dependencies.
+	* configure.in: Do not configure getopt, as gnulib does that now.
+	* make-dist: Do not worry about lib-src/getopt.h, as gnulib handles
+	getopt now, in lib.
+	
 	Regenerate.
 	* arg-nonnull.h, c++defs.h, lib/mktime-internal.h, lib/mktime.c:
 	* lib/stddef.in.h, lib/time.h, lib/time.in.h, lib/time_r.c:

=== modified file 'Makefile.in'
--- Makefile.in	2011-01-09 04:31:19 +0000
+++ Makefile.in	2011-01-09 07:29:26 +0000
@@ -330,7 +330,7 @@
 # Update modules from gnulib, for maintainers, who should have it in
 # $(gnulib_srcdir) (relative to $(srcdir) and should have build tools
 # as per $(gnulib_srcdir)/DEPENDENCIES.
-GNULIB_MODULES = ftoastr mktime
+GNULIB_MODULES = ftoastr getopt-gnu mktime
 GNULIB_TOOL_FLAGS = \
  --import --no-changelog --no-vc-files --makefile-name=gnulib.mk
 sync-from-gnulib: $(gnulib_srcdir)
@@ -401,7 +401,7 @@
 config.status: ${srcdir}/configure ${srcdir}/lisp/version.el
 	./config.status --recheck
 
-AUTOCONF_INPUTS = @MAINT@ $(srcdir)/configure.in $(srcdir)/m4/getopt.m4 $(srcdir)/aclocal.m4
+AUTOCONF_INPUTS = @MAINT@ $(srcdir)/configure.in $(srcdir)/aclocal.m4
 
 $(srcdir)/configure: $(AUTOCONF_INPUTS)
 	cd ${srcdir} && autoconf

=== modified file 'configure.in'
--- configure.in	2011-01-09 04:31:19 +0000
+++ configure.in	2011-01-09 07:29:26 +0000
@@ -2657,15 +2657,6 @@
 
 AC_FUNC_FSEEKO
 
-# Configure getopt.
-m4_include([m4/getopt.m4])
-gl_GETOPT_IFELSE([
-  gl_GETOPT_SUBSTITUTE_HEADER
-  gl_PREREQ_GETOPT
-  GETOPTOBJS='getopt.o getopt1.o'
-])
-AC_SUBST(GETOPTOBJS)
-
 AC_FUNC_GETPGRP
 
 # Configure gnulib.

=== modified file 'lib-src/Makefile.in'
--- lib-src/Makefile.in	2011-01-08 21:02:38 +0000
+++ lib-src/Makefile.in	2011-01-09 07:29:26 +0000
@@ -279,7 +279,7 @@
 	fi
 
 mostlyclean:
-	-rm -f core *.o getopt.h getopt.h-t
+	-rm -f core *.o
 
 clean: mostlyclean
 	-rm -f ${INSTALLABLES} ${UTILITIES} ${DONT_INSTALL}
@@ -311,20 +311,6 @@
 	$(CC) ${ALL_CFLAGS} -o test-distrib ${srcdir}/test-distrib.c
 	./test-distrib ${srcdir}/testfile
 
-## We need the following in order to create a <getopt.h> when the system
-## does not have one that works with the given compiler.
-GETOPT_H = @GETOPT_H@
-getopt.h: getopt_.h
-	cp $(srcdir)/getopt_.h $@-t
-	mv $@-t $@
-
-GETOPTOBJS = @GETOPTOBJS@
-GETOPTDEPS = $(GETOPTOBJS) $(GETOPT_H)
-getopt.o: ${srcdir}/getopt.c $(GETOPT_H) ${srcdir}/gettext.h
-	${CC} -c ${CPP_CFLAGS} ${srcdir}/getopt.c
-getopt1.o: ${srcdir}/getopt1.c $(GETOPT_H)
-	${CC} -c ${CPP_CFLAGS} ${srcdir}/getopt1.c
-
 ../lib/libgnu.a: ../src/config.h
 	cd ../lib && $(MAKE) libgnu.a
 
@@ -335,20 +321,20 @@
 	${CC} -c ${CPP_CFLAGS} -DCONFIG_BROKETS -DINHIBIT_STRING_HEADER \
 	  ${srcdir}/../src/regex.c
 
-etags${EXEEXT}: ${srcdir}/etags.c $(GETOPTDEPS) $(REGEXPDEPS) ../src/config.h
+etags${EXEEXT}: ${srcdir}/etags.c $(REGEXPDEPS) ../src/config.h
 	$(CC) ${ALL_CFLAGS} -DEMACS_NAME="\"GNU Emacs\"" \
-	  -DVERSION="\"${version}\"" ${srcdir}/etags.c $(GETOPTOBJS) \
+	  -DVERSION="\"${version}\"" ${srcdir}/etags.c \
 	  $(REGEXPOBJ) $(LOADLIBES) -o etags
 
-ebrowse${EXEEXT}: ${srcdir}/ebrowse.c $(GETOPTDEPS) ../src/config.h
+ebrowse${EXEEXT}: ${srcdir}/ebrowse.c ../src/config.h
 	$(CC) ${ALL_CFLAGS} -DVERSION="\"${version}\"" \
-	  ${srcdir}/ebrowse.c $(GETOPTOBJS) $(LOADLIBES) -o ebrowse
+	  ${srcdir}/ebrowse.c $(LOADLIBES) -o ebrowse
 
 ## We depend on etags to assure that parallel makes do not write two
 ## etags.o files on top of each other.
 ctags${EXEEXT}: etags${EXEEXT}
 	$(CC) ${ALL_CFLAGS} -DCTAGS -DEMACS_NAME="\"GNU Emacs\"" \
-	  -DVERSION="\"${version}\"" ${srcdir}/etags.c $(GETOPTOBJS) \
+	  -DVERSION="\"${version}\"" ${srcdir}/etags.c \
 	  $(REGEXPOBJ) $(LOADLIBES) -o ctags
 
 profile${EXEEXT}: ${srcdir}/profile.c ../src/config.h
@@ -358,11 +344,11 @@
 	$(CC) ${ALL_CFLAGS} ${srcdir}/make-docfile.c $(LOADLIBES) \
 	  -o make-docfile
 
-movemail${EXEEXT}: movemail.o pop.o $(GETOPTDEPS)
+movemail${EXEEXT}: movemail.o pop.o
 	$(CC) ${LINK_CFLAGS} ${MOVE_FLAGS} movemail.o pop.o \
-	  $(GETOPTOBJS) $(LOADLIBES) $(LIBS_MOVE) -o movemail
+	  $(LOADLIBES) $(LIBS_MOVE) -o movemail
 
-movemail.o: ${srcdir}/movemail.c ../src/config.h $(GETOPT_H)
+movemail.o: ${srcdir}/movemail.c ../src/config.h
 	$(CC) -c ${CPP_CFLAGS} ${MOVE_FLAGS} ${srcdir}/movemail.c
 
 pop.o: ${srcdir}/pop.c  ../src/config.h
@@ -371,19 +357,19 @@
 fakemail${EXEEXT}: ${srcdir}/fakemail.c ../src/config.h
 	$(CC) ${ALL_CFLAGS} ${srcdir}/fakemail.c $(LOADLIBES) -o fakemail
 
-emacsclient${EXEEXT}: ${srcdir}/emacsclient.c ../src/config.h $(GETOPTDEPS)
-	$(CC) ${ALL_CFLAGS} ${srcdir}/emacsclient.c $(GETOPTOBJS)  \
+emacsclient${EXEEXT}: ${srcdir}/emacsclient.c ../src/config.h
+	$(CC) ${ALL_CFLAGS} ${srcdir}/emacsclient.c \
 	   -DVERSION="\"${version}\"" \
 	   $(LOADLIBES) -o emacsclient
 
 hexl${EXEEXT}: ${srcdir}/hexl.c ../src/config.h
 	$(CC) ${ALL_CFLAGS} ${srcdir}/hexl.c $(LOADLIBES) -o hexl
 
-update-game-score${EXEEXT}: update-game-score.o $(GETOPTDEPS)
-	$(CC) ${LINK_CFLAGS} update-game-score.o $(GETOPTOBJS) \
+update-game-score${EXEEXT}: update-game-score.o
+	$(CC) ${LINK_CFLAGS} update-game-score.o \
 	  $(LOADLIBES) -o update-game-score
 
-update-game-score.o: ${srcdir}/update-game-score.c ../src/config.h $(GETOPT_H)
+update-game-score.o: ${srcdir}/update-game-score.c ../src/config.h
 	$(CC) -c ${CPP_CFLAGS} ${srcdir}/update-game-score.c \
 	  -DHAVE_SHARED_GAME_DIR="\"$(gamedir)\""
 

=== modified file 'make-dist'
--- make-dist	2011-01-09 04:31:19 +0000
+++ make-dist	2011-01-09 07:29:26 +0000
@@ -384,9 +384,7 @@
  ln [a-zA-Z]*.[ch] ../${tempdir}/lib-src
  ln ChangeLog Makefile.in README testfile vcdiff ../${tempdir}/lib-src
  ln grep-changelog rcs2log rcs-checkin ../${tempdir}/lib-src
- ln makefile.w32-in ../${tempdir}/lib-src
- cd ../${tempdir}/lib-src
- rm -f getopt.h)
+ ln makefile.w32-in ../${tempdir}/lib-src)
 
 echo "Making links to \`m4'"
 (cd m4

Re: syncing Emacs from sources maintained elsewhere

[Miles Bader]

BTW, is "lib/" the standard subdirectory in which to put stuff from
gnulib in a project?

Thanks,

-Miles

-- 
Cannon, n. An instrument employed in the rectification of national boundaries.

Re: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/10/2011 05:38 PM, Miles Bader wrote:
> is "lib/" the standard subdirectory in which to put stuff from
> gnulib in a project?

Yes, that's the default.  If some other name is preferred
that can easily be done with gnulib-tool's
--source-base=DIRECTORY option.

Re: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

No further comment to my suggestion to sync some gnulib files to Emacs
<http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00328.html>,
so I installed that as revision 102878 on the Emacs trunk.  I also regenerated
the source files by invoking "make sync-from-gnulib", and installed
one or two minor related fixups involving "make maintainer-clean".

When time permits I'd like to look into syncing a few other modules
such as strftime.  These will take a bit more work, since Emacs and
gnulib have diverged, and I plan to focus on modules where merging is
easy.

Re: syncing Emacs from sources maintained elsewhere

[Stefan Monnier]

> No further comment to my suggestion to sync some gnulib files to Emacs
> <http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00328.html>,
> so I installed that as revision 102878 on the Emacs trunk.  I also regenerated
> the source files by invoking "make sync-from-gnulib", and installed
> one or two minor related fixups involving "make maintainer-clean".

Thank you very much.
Could you a little blurb somewhere in admin/notes/* so that someone who
wants to re-sync those gnulib files, will know to do "make
sync-from-gnulib"?  [ If I were that someone I'd "grep -i gnulib
notes/*" so the exact place where you put it is up to you. ]


        Stefan

Re: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/17/2011 01:35 PM, Stefan Monnier wrote:
> Could you a little blurb somewhere in admin/notes/* so that someone who
> wants to re-sync those gnulib files, will know to do "make
> sync-from-gnulib"?

Sure, I added this to admin/notes/bzr:

* Installing changes from gnulib
Some of the files in Emacs are copied from gnulib.  To synchronize
these files from the version of gnulib that you have checked out into
a sibling directory of your branch, type "make sync-from-gnulib"; this
will check out the latest version of gnulib if there is no sibling
directory already.  It is a good idea to run "bzr status" afterwards,
so that if a gnulib module added a file, you can record the new file            
using "bzr add".  After synchronizing from gnulib, do a "make" in the           
usual way.                                                                      
                                                                                
To change the set of gnulib modules, change the GNULIB_MODULES                  
variable in the top-level Makefile.in, and then run:                            
                                                                                
  ./config.status                                                               
  make sync-from-gnulib                                                         
  bzr status                                                                    
                                                                                
The last command will mention files that may need to be added using             
"bzr add".  If you remove a gnulib module, or if a gnulib module                
removes a file, then remove the corresponding files by hand.                    

Re: syncing Emacs from sources maintained elsewhere

[Andy Moreton]

On Mon 17 Jan 2011, Paul Eggert wrote:
> No further comment to my suggestion to sync some gnulib files to Emacs
> <http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00328.html>,
> so I installed that as revision 102878 on the Emacs trunk.  I also
> regenerated the source files by invoking "make sync-from-gnulib", and
> installed one or two minor related fixups involving "make
> maintainer-clean".
>
> When time permits I'd like to look into syncing a few other modules
> such as strftime.  These will take a bit more work, since Emacs and
> gnulib have diverged, and I plan to focus on modules where merging is
> easy.

The changes to update gnulib break the Windows build, which will no
longer bootstrap. It seems that the new lib dir needs a makefile.win-in
and some work on the build scripts similar to the old lib-src dir.

    AndyM

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Tue, 18 Jan 2011 10:11:17 +0000
> 
> The changes to update gnulib break the Windows build, which will no
> longer bootstrap. It seems that the new lib dir needs a makefile.win-in
> and some work on the build scripts similar to the old lib-src dir.

I would suggest that Paul at least takes a look at how non-Posix
platforms build Emacs, to avoid similar breakage in the future.
There's no requirement for taking care of those platforms whenever
such changes are installed, but at least announcing the expected
problems and asking for ways of implementing the change that would
minimize the work to unbreak them, would be nice.

Re: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/18/11 07:20, Eli Zaretskii wrote:
> I would suggest that Paul at least takes a look at how non-Posix
> platforms build Emacs, to avoid similar breakage in the future.

Sorry, I had assumed that the Microsoft builds were done
fairly automatically and had not realized the extent to
which they're maintained by hand.

Here are some things that you should be looking out for:

* lib/Makefile needs to be built.  You can see the set of
  substitutions that need to be done, near the start of
  lib/Makefile.in.  Most of these (e.g., GNULIB_SYMLINKAT)
  can be defined to be empty, since they're Posix interfaces
  that presumably Microsoft does not supply, so I suggest having
  defaulting @FOO@ to be the empty string.

* lib-src/Makefile now refers to ../lib/libgnu.a, and that
  may have a different extension on non-Posix hosts.  Similarly
  for src/Makefile.

* Look for new symbols in config.in that need to be configured
  manually.  Most of the new symbols can be left alone
  (e.g., AA_APPLE_UNIVERSAL_BUILD, GNULIB_TEST_TIME_R,
  HAVE_RAW_DECL_ENDUSERSHELL), but if Microsoft supplies
  a Posix-like interface I expect you'll need to define that
  (HAVE_DECL_GETENV, say? sorry, I'm no expert).

Also, for the recent performance improvement in src/lisp.h:

* HAVE_ATTRIBUTE_ALIGNED should be #defined to be 1 if
  GCC-style __attribute__ ((__aligned__ (EXPR))) works.

* If malloc always returns a multiple of 8, that should be
  added to src/lisp.h (look for "defined __sun").

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> Date: Tue, 18 Jan 2011 10:13:22 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
> 
> On 01/18/11 07:20, Eli Zaretskii wrote:
> > I would suggest that Paul at least takes a look at how non-Posix
> > platforms build Emacs, to avoid similar breakage in the future.
> 
> Sorry, I had assumed that the Microsoft builds were done
> fairly automatically and had not realized the extent to
> which they're maintained by hand.

Anything that's based on running the configure script must be replaced
on these platforms.

> * Look for new symbols in config.in that need to be configured
>   manually.

Can you post a list of those new symbols, please?

Re: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/18/11 14:57, Eli Zaretskii wrote:
>> From: Paul Eggert <eggert@cs.ucla.edu>
> 
>> * Look for new symbols in config.in that need to be configured
>>   manually.
> 
> Can you post a list of those new symbols, please?

You can see a complete list of all the symbols I recently changed by
running this:

  bzr diff -r102854..102889 src/config.in

(If this isn't easy for you to run, please let me know and I'll send
out the full list.)

Most of these symbols, I expect, you won't need to worry about, since
they default to assuming that a feature is absent, and that assumption
will be correct for Microsoft platforms.  Since I don't know
Microsoft, I don't know exactly which symbols actually need to be
worried about.  However, I suggest looking at these symbols more
carefully, as they may need to be defined.  The other new
symbols, I expect, you don't need to define.

   /* Define to 1 if GCC-style __attribute__ ((__aligned__ (expr))) works. */
   #undef HAVE_ATTRIBUTE_ALIGNED

   /* Define to 1 if strtold conforms to C99. */
   #undef HAVE_C99_STRTOLD

   /* Define to `__inline__' or `__inline' if that's what the C compiler
      calls it, or to nothing if 'inline' is not supported under any name.  */
   #ifndef __cplusplus
   #undef inline
   #endif

   /* Define to the equivalent of the C99 'restrict' keyword, or to
      nothing if this is not supported.  Do not define if restrict is
      supported directly.  */
   #undef restrict


Also, you no longer need to worry about the following symbols, since
they were removed from config.in:

   /* Define to 1 if the mktime function is broken. */
   #undef BROKEN_MKTIME

   /* Define to 1 if you have the `mktime' function. */
   #undef HAVE_MKTIME

   /* Define to compiler's equivalent of C99 restrict keyword. Don't define if
      equivalent is `__restrict'. */
   #undef __restrict

Re: syncing Emacs from sources maintained elsewhere

[Glenn Morris]

In case you don't follow the bug list, the Mac (nextstep) port seems
unhappy with the changes:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7856
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7859

[compiling unexmacosx.c]
In file included from ../lib/unistd.h:110,
                 from unexmacosx.c:94:
../lib/getopt.h:196: error: redefinition of 'struct option'

bug#7859: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/18/2011 05:20 PM, Glenn Morris wrote:

> the Mac (nextstep) port seems unhappy with the changes:
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7856
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7859
> 
> [compiling unexmacosx.c]
> In file included from ../lib/unistd.h:110,
>                  from unexmacosx.c:94:
> ../lib/getopt.h:196: error: redefinition of 'struct option'

Thanks for mentioning that, as I don't follow the bug list.
This almost certainly seems to be a bug with gnulib's treatment
of getopt.h and unistd.h.

gnulib's unistd.h includes its getopt.h, which defines 'struct
option'.  I suspect the problem is that MacOS X already defines
'struct option' somewhere; or perhaps somehow we're including both the
MacOS X 'getopt.h' and Emacs's getopt.h.

What does src/config.h #define __GETOPT_PREFIX to?

Would it be possible to send the output of the command of "gcc -E",
e.g., something like this (substituting the -I options that the failed
compile used)?

  gcc -E -Demacs -DHAVE_CONFIG_H -I. -I/usr/local/emacs/trunk/src -I../lib \
    -I/usr/local/emacs/trunk/src/../lib -I/opt/local/include/libxml2 \
    -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include \
    -I/opt/local/include \
    unexmacosx.c

That would help us find out which earlier header file is defining
'struct option'.  Also, it might be helpful to know what src/config.h
looks like.  Unfortunately I do not have access to a Mac OS X host
so I can't debug this directly.

bug#7856: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/18/2011 05:20 PM, Glenn Morris wrote:

> the Mac (nextstep) port seems unhappy with the changes:
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7856
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7859
> 
> [compiling unexmacosx.c]
> In file included from ../lib/unistd.h:110,
>                  from unexmacosx.c:94:
> ../lib/getopt.h:196: error: redefinition of 'struct option'

Thanks for mentioning that, as I don't follow the bug list.
This almost certainly seems to be a bug with gnulib's treatment
of getopt.h and unistd.h.

gnulib's unistd.h includes its getopt.h, which defines 'struct
option'.  I suspect the problem is that MacOS X already defines
'struct option' somewhere; or perhaps somehow we're including both the
MacOS X 'getopt.h' and Emacs's getopt.h.

What does src/config.h #define __GETOPT_PREFIX to?

Would it be possible to send the output of the command of "gcc -E",
e.g., something like this (substituting the -I options that the failed
compile used)?

  gcc -E -Demacs -DHAVE_CONFIG_H -I. -I/usr/local/emacs/trunk/src -I../lib \
    -I/usr/local/emacs/trunk/src/../lib -I/opt/local/include/libxml2 \
    -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include \
    -I/opt/local/include \
    unexmacosx.c

That would help us find out which earlier header file is defining
'struct option'.  Also, it might be helpful to know what src/config.h
looks like.  Unfortunately I do not have access to a Mac OS X host
so I can't debug this directly.

Re: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/18/2011 05:20 PM, Glenn Morris wrote:

> the Mac (nextstep) port seems unhappy with the changes:
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7856
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7859
> 
> [compiling unexmacosx.c]
> In file included from ../lib/unistd.h:110,
>                  from unexmacosx.c:94:
> ../lib/getopt.h:196: error: redefinition of 'struct option'

Thanks for mentioning that, as I don't follow the bug list.
This almost certainly seems to be a bug with gnulib's treatment
of getopt.h and unistd.h.

gnulib's unistd.h includes its getopt.h, which defines 'struct
option'.  I suspect the problem is that MacOS X already defines
'struct option' somewhere; or perhaps somehow we're including both the
MacOS X 'getopt.h' and Emacs's getopt.h.

What does src/config.h #define __GETOPT_PREFIX to?

Would it be possible to send the output of the command of "gcc -E",
e.g., something like this (substituting the -I options that the failed
compile used)?

  gcc -E -Demacs -DHAVE_CONFIG_H -I. -I/usr/local/emacs/trunk/src -I../lib \
    -I/usr/local/emacs/trunk/src/../lib -I/opt/local/include/libxml2 \
    -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include \
    -I/opt/local/include \
    unexmacosx.c

That would help us find out which earlier header file is defining
'struct option'.  Also, it might be helpful to know what src/config.h
looks like.  Unfortunately I do not have access to a Mac OS X host
so I can't debug this directly.

Re: syncing Emacs from sources maintained elsewhere

[Glenn Morris]

Jan Djärv wrote:

> Preprocessed sources attached.

300kb * 4 mailing list addresses.
Grumble, gzip, grumble...

bug#7856: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

I got a copy of preprocessed sources from bryan d. o'connor.
Here's what seems to be the problem:

* <config.h> has "#define __GETOPT_PREFIX rpl_" as expected.

* unexmacosx.c includes the Gnulib <unistd.h>.

* The Gnulib <unistd.h> includes the system unistd.h, which declares
  the getopt-related names itself (without including anything) and then finishes.

* The Gnulib <unistd.h> then includes the Gnulib <getopt.h>.

* The Gnulib <getopt.h> includes the system getopt.h.

* The system getopt.h includes the Gnulib <unistd.h>.

* This inner Gnulib <unistd.h> does nothing, and finishes.

* The system getopt.h declares 'struct option' and other stuff, and finishes.

* The Gnulib <getopt.h> then does this:

     #if defined __GETOPT_PREFIX && !defined __need_getopt
     # if !@HAVE_GETOPT_H@
     #  include <stdlib.h>
     #  include <stdio.h>
     #  include <unistd.h>
     # endif
     # undef __need_getopt
     ...
     # undef option
     # define __GETOPT_CONCAT(x, y) x ## y
     # define __GETOPT_XCONCAT(x, y) __GETOPT_CONCAT (x, y)
     # define __GETOPT_ID(y) __GETOPT_XCONCAT (__GETOPT_PREFIX, y)
     ...
     # define option __GETOPT_ID (option)
     ...
     #endif

* This should "#define option rpl_option", but apparently it doesn't.

* Presumably __GETOPT_PREFIX is defined, but __need_getopt is also defined,
  so the entire #if is skipped.

* And when Gnulib <getopt.h> declares a 'struct option', this clashes
  with the 'struct option' declared in the system getopt.h.
       
If my analysis is right, we need to figure out why __need_getopt is
defined.  Can you send the output of the following?

cd emacs
grep -r __need_getopt . /usr/include


PS.  This all seems to be a case where we should be using Gnulib's
identifier replacement mechanism, but I don't understand it that
well and if memory serves it doesn't work with struct tags anyway.

bug#7859: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

I got a copy of preprocessed sources from bryan d. o'connor.
Here's what seems to be the problem:

* <config.h> has "#define __GETOPT_PREFIX rpl_" as expected.

* unexmacosx.c includes the Gnulib <unistd.h>.

* The Gnulib <unistd.h> includes the system unistd.h, which declares
  the getopt-related names itself (without including anything) and then finishes.

* The Gnulib <unistd.h> then includes the Gnulib <getopt.h>.

* The Gnulib <getopt.h> includes the system getopt.h.

* The system getopt.h includes the Gnulib <unistd.h>.

* This inner Gnulib <unistd.h> does nothing, and finishes.

* The system getopt.h declares 'struct option' and other stuff, and finishes.

* The Gnulib <getopt.h> then does this:

     #if defined __GETOPT_PREFIX && !defined __need_getopt
     # if !@HAVE_GETOPT_H@
     #  include <stdlib.h>
     #  include <stdio.h>
     #  include <unistd.h>
     # endif
     # undef __need_getopt
     ...
     # undef option
     # define __GETOPT_CONCAT(x, y) x ## y
     # define __GETOPT_XCONCAT(x, y) __GETOPT_CONCAT (x, y)
     # define __GETOPT_ID(y) __GETOPT_XCONCAT (__GETOPT_PREFIX, y)
     ...
     # define option __GETOPT_ID (option)
     ...
     #endif

* This should "#define option rpl_option", but apparently it doesn't.

* Presumably __GETOPT_PREFIX is defined, but __need_getopt is also defined,
  so the entire #if is skipped.

* And when Gnulib <getopt.h> declares a 'struct option', this clashes
  with the 'struct option' declared in the system getopt.h.
       
If my analysis is right, we need to figure out why __need_getopt is
defined.  Can you send the output of the following?

cd emacs
grep -r __need_getopt . /usr/include


PS.  This all seems to be a case where we should be using Gnulib's
identifier replacement mechanism, but I don't understand it that
well and if memory serves it doesn't work with struct tags anyway.

Re: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

I got a copy of preprocessed sources from bryan d. o'connor.
Here's what seems to be the problem:

* <config.h> has "#define __GETOPT_PREFIX rpl_" as expected.

* unexmacosx.c includes the Gnulib <unistd.h>.

* The Gnulib <unistd.h> includes the system unistd.h, which declares
  the getopt-related names itself (without including anything) and then finishes.

* The Gnulib <unistd.h> then includes the Gnulib <getopt.h>.

* The Gnulib <getopt.h> includes the system getopt.h.

* The system getopt.h includes the Gnulib <unistd.h>.

* This inner Gnulib <unistd.h> does nothing, and finishes.

* The system getopt.h declares 'struct option' and other stuff, and finishes.

* The Gnulib <getopt.h> then does this:

     #if defined __GETOPT_PREFIX && !defined __need_getopt
     # if !@HAVE_GETOPT_H@
     #  include <stdlib.h>
     #  include <stdio.h>
     #  include <unistd.h>
     # endif
     # undef __need_getopt
     ...
     # undef option
     # define __GETOPT_CONCAT(x, y) x ## y
     # define __GETOPT_XCONCAT(x, y) __GETOPT_CONCAT (x, y)
     # define __GETOPT_ID(y) __GETOPT_XCONCAT (__GETOPT_PREFIX, y)
     ...
     # define option __GETOPT_ID (option)
     ...
     #endif

* This should "#define option rpl_option", but apparently it doesn't.

* Presumably __GETOPT_PREFIX is defined, but __need_getopt is also defined,
  so the entire #if is skipped.

* And when Gnulib <getopt.h> declares a 'struct option', this clashes
  with the 'struct option' declared in the system getopt.h.
       
If my analysis is right, we need to figure out why __need_getopt is
defined.  Can you send the output of the following?

cd emacs
grep -r __need_getopt . /usr/include


PS.  This all seems to be a case where we should be using Gnulib's
identifier replacement mechanism, but I don't understand it that
well and if memory serves it doesn't work with struct tags anyway.

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> Date: Tue, 18 Jan 2011 16:36:04 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: andrewjmoreton@gmail.com, emacs-devel@gnu.org
> 
> You can see a complete list of all the symbols I recently changed by
> running this:
> 
>   bzr diff -r102854..102889 src/config.in

Thanks (for this and the rest of info).

> (If this isn't easy for you to run, please let me know and I'll send
> out the full list.)

No need, bzr works very well on Windows.

bug#7859: syncing Emacs from sources maintained elsewhere

[Jan Djärv]

Paul Eggert skrev 2011-01-19 11.38:
> grep -r __need_getopt . /usr/include


grep -nr __need_getopt . /usr/include
./lib/getopt.h:38:#ifndef __need_getopt
./lib/getopt.h:51:#if defined __GETOPT_PREFIX && !defined __need_getopt
./lib/getopt.h:57:# undef __need_getopt
./lib/getopt.h:86:   This used to be `#if defined __GETOPT_PREFIX && !defined 
__need_getopt',
./lib/getopt.h:89:   __need_getopt.
./lib/getopt.h:93:   only if __need_getopt is not defined, so it is quite safe 
to rewrite
./lib/getopt.h:96:#if !defined __need_getopt
./lib/getopt.h:173:#ifndef __need_getopt
./lib/getopt.h:241:#ifndef __need_getopt
./lib/getopt.h:258:#undef __need_getopt
./lib/getopt.in.h:37:#ifndef __need_getopt
./lib/getopt.in.h:50:#if defined __GETOPT_PREFIX && !defined __need_getopt
./lib/getopt.in.h:56:# undef __need_getopt
./lib/getopt.in.h:85:   This used to be `#if defined __GETOPT_PREFIX && 
!defined __need_getopt',
./lib/getopt.in.h:88:   __need_getopt.
./lib/getopt.in.h:92:   only if __need_getopt is not defined, so it is quite 
safe to rewrite
./lib/getopt.in.h:95:#if !defined __need_getopt
./lib/getopt.in.h:162:#ifndef __need_getopt
./lib/getopt.in.h:230:#ifndef __need_getopt
./lib/getopt.in.h:247:#undef __need_getopt

	Jan D.

bug#7856: bug#7859: syncing Emacs from sources maintained elsewhere

[Jan Djärv]

Paul Eggert skrev 2011-01-19 11.38:
> grep -r __need_getopt . /usr/include


grep -nr __need_getopt . /usr/include
./lib/getopt.h:38:#ifndef __need_getopt
./lib/getopt.h:51:#if defined __GETOPT_PREFIX && !defined __need_getopt
./lib/getopt.h:57:# undef __need_getopt
./lib/getopt.h:86:   This used to be `#if defined __GETOPT_PREFIX && !defined 
__need_getopt',
./lib/getopt.h:89:   __need_getopt.
./lib/getopt.h:93:   only if __need_getopt is not defined, so it is quite safe 
to rewrite
./lib/getopt.h:96:#if !defined __need_getopt
./lib/getopt.h:173:#ifndef __need_getopt
./lib/getopt.h:241:#ifndef __need_getopt
./lib/getopt.h:258:#undef __need_getopt
./lib/getopt.in.h:37:#ifndef __need_getopt
./lib/getopt.in.h:50:#if defined __GETOPT_PREFIX && !defined __need_getopt
./lib/getopt.in.h:56:# undef __need_getopt
./lib/getopt.in.h:85:   This used to be `#if defined __GETOPT_PREFIX && 
!defined __need_getopt',
./lib/getopt.in.h:88:   __need_getopt.
./lib/getopt.in.h:92:   only if __need_getopt is not defined, so it is quite 
safe to rewrite
./lib/getopt.in.h:95:#if !defined __need_getopt
./lib/getopt.in.h:162:#ifndef __need_getopt
./lib/getopt.in.h:230:#ifndef __need_getopt
./lib/getopt.in.h:247:#undef __need_getopt

	Jan D.

Re: bug#7859: syncing Emacs from sources maintained elsewhere

[Jan Djärv]

Paul Eggert skrev 2011-01-19 11.38:
> grep -r __need_getopt . /usr/include


grep -nr __need_getopt . /usr/include
./lib/getopt.h:38:#ifndef __need_getopt
./lib/getopt.h:51:#if defined __GETOPT_PREFIX && !defined __need_getopt
./lib/getopt.h:57:# undef __need_getopt
./lib/getopt.h:86:   This used to be `#if defined __GETOPT_PREFIX && !defined 
__need_getopt',
./lib/getopt.h:89:   __need_getopt.
./lib/getopt.h:93:   only if __need_getopt is not defined, so it is quite safe 
to rewrite
./lib/getopt.h:96:#if !defined __need_getopt
./lib/getopt.h:173:#ifndef __need_getopt
./lib/getopt.h:241:#ifndef __need_getopt
./lib/getopt.h:258:#undef __need_getopt
./lib/getopt.in.h:37:#ifndef __need_getopt
./lib/getopt.in.h:50:#if defined __GETOPT_PREFIX && !defined __need_getopt
./lib/getopt.in.h:56:# undef __need_getopt
./lib/getopt.in.h:85:   This used to be `#if defined __GETOPT_PREFIX && 
!defined __need_getopt',
./lib/getopt.in.h:88:   __need_getopt.
./lib/getopt.in.h:92:   only if __need_getopt is not defined, so it is quite 
safe to rewrite
./lib/getopt.in.h:95:#if !defined __need_getopt
./lib/getopt.in.h:162:#ifndef __need_getopt
./lib/getopt.in.h:230:#ifndef __need_getopt
./lib/getopt.in.h:247:#undef __need_getopt

	Jan D.

bug#7856: bug#7859: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

I see that Jan Djärv tracked the problem down:
unexmacosx.c included <unistd.h> before <config.h>,
and this caused the problem.  Generally speaking, <config.h>
should be included before all other files, since it
defines macros such as _FILE_OFFSET_BITS that may affect
the ABI, and compiling files sometimes with one ABI and
sometimes with another can lead to disaster.

I see that unexmacos.c still doesn't include <config.h> first,
though.  I suggest that it be changed to do that.

A quick scan for other files with the problem show that
the following files probably need the "#include <config.h>"
moved to the top too:

  w32.c
  w32proc.c

bug#7859: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

I see that Jan Djärv tracked the problem down:
unexmacosx.c included <unistd.h> before <config.h>,
and this caused the problem.  Generally speaking, <config.h>
should be included before all other files, since it
defines macros such as _FILE_OFFSET_BITS that may affect
the ABI, and compiling files sometimes with one ABI and
sometimes with another can lead to disaster.

I see that unexmacos.c still doesn't include <config.h> first,
though.  I suggest that it be changed to do that.

A quick scan for other files with the problem show that
the following files probably need the "#include <config.h>"
moved to the top too:

  w32.c
  w32proc.c

Re: bug#7859: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

I see that Jan Djärv tracked the problem down:
unexmacosx.c included <unistd.h> before <config.h>,
and this caused the problem.  Generally speaking, <config.h>
should be included before all other files, since it
defines macros such as _FILE_OFFSET_BITS that may affect
the ABI, and compiling files sometimes with one ABI and
sometimes with another can lead to disaster.

I see that unexmacos.c still doesn't include <config.h> first,
though.  I suggest that it be changed to do that.

A quick scan for other files with the problem show that
the following files probably need the "#include <config.h>"
moved to the top too:

  w32.c
  w32proc.c

Re: bug#7859: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

One minor thing: the recent change to get trunk builds working
on MacOS X unfortunately broke builds under GNU/Linux with X11.
I installed this further patch; hope it's OK.

Fix X11 compilation failure.
* globals.h (struct emacs_globals): Document f_Vselection_alist.
* xselect.c (Vselection_alist): Remove declaration, moving its
documentation to globals.h.  This fixes a compilation failure
induced by the earlier change to globals.h today.
=== modified file 'src/globals.h'
--- src/globals.h	2011-01-19 22:11:33 +0000
+++ src/globals.h	2011-01-19 23:28:30 +0000
@@ -1751,6 +1751,19 @@

   Lisp_Object f_Vns_sent_selection_hooks;
   Lisp_Object f_Vns_lost_selection_hooks;
+
+  /* This is an association list whose elements are of the form
+       ( SELECTION-NAME SELECTION-VALUE SELECTION-TIMESTAMP FRAME)
+     SELECTION-NAME is a lisp symbol, whose name is the name of an X Atom.
+     SELECTION-VALUE is the value that emacs owns for that selection.
+       It may be any kind of Lisp object.
+     SELECTION-TIMESTAMP is the time at which emacs began owning this
+       selection, as a cons of two 16-bit numbers (making a 32 bit time.)
+     FRAME is the frame for which we made the selection.
+     If there is an entry in this alist, then it can be assumed that Emacs owns
+      that selection.
+     The only (eq) parts of this list that are visible from Lisp are the
+      selection-values.  */
   Lisp_Object f_Vselection_alist;

   Lisp_Object f_Vns_reg_to_script;
=== modified file 'src/xselect.c'
--- src/xselect.c	2011-01-18 20:45:37 +0000
+++ src/xselect.c	2011-01-19 23:28:37 +0000
@@ -127,20 +127,6 @@
 /* Defined in keyboard.c.  */
 extern unsigned long last_event_timestamp;

-/* This is an association list whose elements are of the form
-     ( SELECTION-NAME SELECTION-VALUE SELECTION-TIMESTAMP FRAME)
-   SELECTION-NAME is a lisp symbol, whose name is the name of an X Atom.
-   SELECTION-VALUE is the value that emacs owns for that selection.
-     It may be any kind of Lisp object.
-   SELECTION-TIMESTAMP is the time at which emacs began owning this selection,
-     as a cons of two 16-bit numbers (making a 32 bit time.)
-   FRAME is the frame for which we made the selection.
-   If there is an entry in this alist, then it can be assumed that Emacs owns
-    that selection.
-   The only (eq) parts of this list that are visible from Lisp are the
-    selection-values.  */
-static Lisp_Object Vselection_alist;
-

 \f
 /* Define a queue to save up SELECTION_REQUEST_EVENT events for later

bug#7859: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> Date: Wed, 19 Jan 2011 15:44:40 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: 7859@debbugs.gnu.org, bug-gnulib <bug-gnulib@gnu.org>, 7856@debbugs.gnu.org,
> 	emacs-devel@gnu.org
> 
> A quick scan for other files with the problem show that
> the following files probably need the "#include <config.h>"
> moved to the top too:
> 
>   w32.c
>   w32proc.c

These two have a comment saying that this is done on purpose:

  /* must include CRT headers *before* config.h */

If someone wants to dig into the reasons, find out why and fix that,
please do.  I had my share of fighting with (and being defeated by)
the order of included headers on Windows, so I'm not volunteering.

Re: bug#7859: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> Date: Wed, 19 Jan 2011 15:44:40 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: 7859@debbugs.gnu.org, bug-gnulib <bug-gnulib@gnu.org>, 7856@debbugs.gnu.org,
> 	emacs-devel@gnu.org
> 
> A quick scan for other files with the problem show that
> the following files probably need the "#include <config.h>"
> moved to the top too:
> 
>   w32.c
>   w32proc.c

These two have a comment saying that this is done on purpose:

  /* must include CRT headers *before* config.h */

If someone wants to dig into the reasons, find out why and fix that,
please do.  I had my share of fighting with (and being defeated by)
the order of included headers on Windows, so I'm not volunteering.

bug#7859: syncing Emacs from sources maintained elsewhere

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On 01/19/2011 03:38 AM, Paul Eggert wrote:
> * unexmacosx.c includes the Gnulib <unistd.h>.

That's always a bug to include any gnulib-provided header prior to
<config.h>.

> 
> * And when Gnulib <getopt.h> declares a 'struct option', this clashes
>   with the 'struct option' declared in the system getopt.h.

And this is a known symptom of violating the above constraint.

>        
> PS.  This all seems to be a case where we should be using Gnulib's
> identifier replacement mechanism, but I don't understand it that
> well and if memory serves it doesn't work with struct tags anyway.

We've managed to modernize other headers to properly declare replacement
structs exactly once; it is merely a matter of someone having enough
time to modernize the gnulib getopt module to use modern constructs
rather than abusing config.h to define an rpl_ prefix.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

bug#7856: syncing Emacs from sources maintained elsewhere

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On 01/19/2011 03:38 AM, Paul Eggert wrote:
> * unexmacosx.c includes the Gnulib <unistd.h>.

That's always a bug to include any gnulib-provided header prior to
<config.h>.

> 
> * And when Gnulib <getopt.h> declares a 'struct option', this clashes
>   with the 'struct option' declared in the system getopt.h.

And this is a known symptom of violating the above constraint.

>        
> PS.  This all seems to be a case where we should be using Gnulib's
> identifier replacement mechanism, but I don't understand it that
> well and if memory serves it doesn't work with struct tags anyway.

We've managed to modernize other headers to properly declare replacement
structs exactly once; it is merely a matter of someone having enough
time to modernize the gnulib getopt module to use modern constructs
rather than abusing config.h to define an rpl_ prefix.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: syncing Emacs from sources maintained elsewhere

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On 01/19/2011 03:38 AM, Paul Eggert wrote:
> * unexmacosx.c includes the Gnulib <unistd.h>.

That's always a bug to include any gnulib-provided header prior to
<config.h>.

> 
> * And when Gnulib <getopt.h> declares a 'struct option', this clashes
>   with the 'struct option' declared in the system getopt.h.

And this is a known symptom of violating the above constraint.

>        
> PS.  This all seems to be a case where we should be using Gnulib's
> identifier replacement mechanism, but I don't understand it that
> well and if memory serves it doesn't work with struct tags anyway.

We've managed to modernize other headers to properly declare replacement
structs exactly once; it is merely a matter of someone having enough
time to modernize the gnulib getopt module to use modern constructs
rather than abusing config.h to define an rpl_ prefix.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: bug#7859: syncing Emacs from sources maintained elsewhere

[Tom Tromey]

>>>>> "Paul" == Paul Eggert <eggert@cs.ucla.edu> writes:

Paul> One minor thing: the recent change to get trunk builds working
Paul> on MacOS X unfortunately broke builds under GNU/Linux with X11.
Paul> I installed this further patch; hope it's OK.

It looks correct to me.

Tom

bug#7859: syncing Emacs from sources maintained elsewhere

[Jan Djärv]

Paul Eggert skrev 2011-01-20 00.44:
> I see that Jan Djärv tracked the problem down:
> unexmacosx.c included<unistd.h>  before<config.h>,
> and this caused the problem.  Generally speaking,<config.h>
> should be included before all other files, since it
> defines macros such as _FILE_OFFSET_BITS that may affect
> the ABI, and compiling files sometimes with one ABI and
> sometimes with another can lead to disaster.
>
> I see that unexmacos.c still doesn't include<config.h>  first,
> though.  I suggest that it be changed to do that.
>

Not possible, I added this comment:

/* config.h #define:s malloc/realloc/free and then includes stdlib.h.
    We want the undefined versions, but if config.h includes stdlib.h
    with the #define:s in place, the prototypes will be wrong and we get
    warnings.  To prevent that, include stdlib.h before config.h.  */

	Jan D.

bug#7856: bug#7859: syncing Emacs from sources maintained elsewhere

[Jan Djärv]

Paul Eggert skrev 2011-01-20 00.44:
> I see that Jan Djärv tracked the problem down:
> unexmacosx.c included<unistd.h>  before<config.h>,
> and this caused the problem.  Generally speaking,<config.h>
> should be included before all other files, since it
> defines macros such as _FILE_OFFSET_BITS that may affect
> the ABI, and compiling files sometimes with one ABI and
> sometimes with another can lead to disaster.
>
> I see that unexmacos.c still doesn't include<config.h>  first,
> though.  I suggest that it be changed to do that.
>

Not possible, I added this comment:

/* config.h #define:s malloc/realloc/free and then includes stdlib.h.
    We want the undefined versions, but if config.h includes stdlib.h
    with the #define:s in place, the prototypes will be wrong and we get
    warnings.  To prevent that, include stdlib.h before config.h.  */

	Jan D.

Re: bug#7859: syncing Emacs from sources maintained elsewhere

[Jan Djärv]

Paul Eggert skrev 2011-01-20 00.44:
> I see that Jan Djärv tracked the problem down:
> unexmacosx.c included<unistd.h>  before<config.h>,
> and this caused the problem.  Generally speaking,<config.h>
> should be included before all other files, since it
> defines macros such as _FILE_OFFSET_BITS that may affect
> the ABI, and compiling files sometimes with one ABI and
> sometimes with another can lead to disaster.
>
> I see that unexmacos.c still doesn't include<config.h>  first,
> though.  I suggest that it be changed to do that.
>

Not possible, I added this comment:

/* config.h #define:s malloc/realloc/free and then includes stdlib.h.
    We want the undefined versions, but if config.h includes stdlib.h
    with the #define:s in place, the prototypes will be wrong and we get
    warnings.  To prevent that, include stdlib.h before config.h.  */

	Jan D.

bug#7856: bug#7859: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/19/2011 10:45 PM, Jan Djärv wrote:
> /* config.h #define:s malloc/realloc/free and then includes stdlib.h.
>    We want the undefined versions, but if config.h includes stdlib.h
>    with the #define:s in place, the prototypes will be wrong and we get
>    warnings.  To prevent that, include stdlib.h before config.h.  */

OK, I see.  There's a better way, one that doesn't potentially mess up
the ABI.  Namely, Emacs can supply a stdlib.h wrapper that #defines
malloc/realloc/free the way we like.  gnulib already does
that, but Emacs doesn't use gnulib's stdlib.h wrapper.
At some point, perhaps Emacs will, and then we can look into
this issue again.

Is stdlib.h the only include file that has the problem?
If so, I suggest modifying unexmacosx.c to include <stdlib.h>
first, <config.h> second, and everything else after that.
That should lessen the likelihood of an ABI mismatch.

If not, then what other include files have the problem?
This issue may come up if we add more wrappers from gnulib.

bug#7859: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/19/2011 10:45 PM, Jan Djärv wrote:
> /* config.h #define:s malloc/realloc/free and then includes stdlib.h.
>    We want the undefined versions, but if config.h includes stdlib.h
>    with the #define:s in place, the prototypes will be wrong and we get
>    warnings.  To prevent that, include stdlib.h before config.h.  */

OK, I see.  There's a better way, one that doesn't potentially mess up
the ABI.  Namely, Emacs can supply a stdlib.h wrapper that #defines
malloc/realloc/free the way we like.  gnulib already does
that, but Emacs doesn't use gnulib's stdlib.h wrapper.
At some point, perhaps Emacs will, and then we can look into
this issue again.

Is stdlib.h the only include file that has the problem?
If so, I suggest modifying unexmacosx.c to include <stdlib.h>
first, <config.h> second, and everything else after that.
That should lessen the likelihood of an ABI mismatch.

If not, then what other include files have the problem?
This issue may come up if we add more wrappers from gnulib.

Re: bug#7859: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/19/2011 10:45 PM, Jan Djärv wrote:
> /* config.h #define:s malloc/realloc/free and then includes stdlib.h.
>    We want the undefined versions, but if config.h includes stdlib.h
>    with the #define:s in place, the prototypes will be wrong and we get
>    warnings.  To prevent that, include stdlib.h before config.h.  */

OK, I see.  There's a better way, one that doesn't potentially mess up
the ABI.  Namely, Emacs can supply a stdlib.h wrapper that #defines
malloc/realloc/free the way we like.  gnulib already does
that, but Emacs doesn't use gnulib's stdlib.h wrapper.
At some point, perhaps Emacs will, and then we can look into
this issue again.

Is stdlib.h the only include file that has the problem?
If so, I suggest modifying unexmacosx.c to include <stdlib.h>
first, <config.h> second, and everything else after that.
That should lessen the likelihood of an ABI mismatch.

If not, then what other include files have the problem?
This issue may come up if we add more wrappers from gnulib.

bug#7859: syncing Emacs from sources maintained elsewhere

[Jan D.]

Paul Eggert skrev 2011-01-20 08:51:
> On 01/19/2011 10:45 PM, Jan Djärv wrote:
>> /* config.h #define:s malloc/realloc/free and then includes stdlib.h.
>>     We want the undefined versions, but if config.h includes stdlib.h
>>     with the #define:s in place, the prototypes will be wrong and we get
>>     warnings.  To prevent that, include stdlib.h before config.h.  */
>
> OK, I see.  There's a better way, one that doesn't potentially mess up
> the ABI.  Namely, Emacs can supply a stdlib.h wrapper that #defines
> malloc/realloc/free the way we like.  gnulib already does
> that, but Emacs doesn't use gnulib's stdlib.h wrapper.
> At some point, perhaps Emacs will, and then we can look into
> this issue again.
>

It is just for unexmacosx.c we want undefined malloc/free/realloc.
For other files we wan't the defined ones.
We can tweek the m/darwin.h file instead where these defines are.

	Jan D.

bug#7856: bug#7859: syncing Emacs from sources maintained elsewhere

[Jan D.]

Paul Eggert skrev 2011-01-20 08:51:
> On 01/19/2011 10:45 PM, Jan Djärv wrote:
>> /* config.h #define:s malloc/realloc/free and then includes stdlib.h.
>>     We want the undefined versions, but if config.h includes stdlib.h
>>     with the #define:s in place, the prototypes will be wrong and we get
>>     warnings.  To prevent that, include stdlib.h before config.h.  */
>
> OK, I see.  There's a better way, one that doesn't potentially mess up
> the ABI.  Namely, Emacs can supply a stdlib.h wrapper that #defines
> malloc/realloc/free the way we like.  gnulib already does
> that, but Emacs doesn't use gnulib's stdlib.h wrapper.
> At some point, perhaps Emacs will, and then we can look into
> this issue again.
>

It is just for unexmacosx.c we want undefined malloc/free/realloc.
For other files we wan't the defined ones.
We can tweek the m/darwin.h file instead where these defines are.

	Jan D.

Re: bug#7859: syncing Emacs from sources maintained elsewhere

[Jan D.]

Paul Eggert skrev 2011-01-20 08:51:
> On 01/19/2011 10:45 PM, Jan Djärv wrote:
>> /* config.h #define:s malloc/realloc/free and then includes stdlib.h.
>>     We want the undefined versions, but if config.h includes stdlib.h
>>     with the #define:s in place, the prototypes will be wrong and we get
>>     warnings.  To prevent that, include stdlib.h before config.h.  */
>
> OK, I see.  There's a better way, one that doesn't potentially mess up
> the ABI.  Namely, Emacs can supply a stdlib.h wrapper that #defines
> malloc/realloc/free the way we like.  gnulib already does
> that, but Emacs doesn't use gnulib's stdlib.h wrapper.
> At some point, perhaps Emacs will, and then we can look into
> this issue again.
>

It is just for unexmacosx.c we want undefined malloc/free/realloc.
For other files we wan't the defined ones.
We can tweek the m/darwin.h file instead where these defines are.

	Jan D.

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> Date: Tue, 18 Jan 2011 10:13:22 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
> 
> * Look for new symbols in config.in that need to be configured
>   manually.  Most of the new symbols can be left alone
>   (e.g., AA_APPLE_UNIVERSAL_BUILD, GNULIB_TEST_TIME_R,
>   HAVE_RAW_DECL_ENDUSERSHELL), but if Microsoft supplies
>   a Posix-like interface I expect you'll need to define that
>   (HAVE_DECL_GETENV, say? sorry, I'm no expert).

It's hard to say what to do with some of these new symbols.  Could
you please clarify by answering the questions below?  I cannot advance
with fixing the Windows build until I understand what to do with them.

 . What is the semantics of the GNULIB_TEST_* macros?  The comments
   say "Define to 1 when the gnulib module FOO should be tested.", but
   what does it mean "should be tested"? tested by whom and at what
   time?

 . Why is NO_MINUS_C_MINUS_O needed?  Which compilation uses this
   macro?

 . Why are PACKAGE and VERSION needed, and where are they used?

TIA

Re: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/23/2011 04:39 AM, Eli Zaretskii wrote:

>  . Why is NO_MINUS_C_MINUS_O needed?  Which compilation uses this
>    macro?

That's an Autoconf thing; gnulib doesn't use it.  I think it's
not needed in config.h, and will look into removing it at
some point.  In the meantime, don't worry about it; it doesn't
affect Emacs.

>  . Why are PACKAGE and VERSION needed, and where are they used?

That's another Automake thing.  PACKAGE should be "emacs",
and VERSION "24.0.50".  VERSION is used in some auxiliary
programs like lib-src/etags.c.  Emacs doesn't use PACKAGE
anywhere now, but perhaps it will someday.

>  . What is the semantics of the GNULIB_TEST_* macros?

You needn't worry about those.  They're already gone from
the Emacs trunk.

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> Date: Sun, 23 Jan 2011 12:38:58 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org, bug-gnulib <bug-gnulib@gnu.org>
> 
> On 01/23/2011 04:39 AM, Eli Zaretskii wrote:
> 
> >  . Why is NO_MINUS_C_MINUS_O needed?  Which compilation uses this
> >    macro?
> 
> That's an Autoconf thing; gnulib doesn't use it.  I think it's
> not needed in config.h, and will look into removing it at
> some point.  In the meantime, don't worry about it; it doesn't
> affect Emacs.
> 
> >  . Why are PACKAGE and VERSION needed, and where are they used?
> 
> That's another Automake thing.  PACKAGE should be "emacs",
> and VERSION "24.0.50".  VERSION is used in some auxiliary
> programs like lib-src/etags.c.  Emacs doesn't use PACKAGE
> anywhere now, but perhaps it will someday.
> 
> >  . What is the semantics of the GNULIB_TEST_* macros?
> 
> You needn't worry about those.  They're already gone from
> the Emacs trunk.

Thanks.

So the only macros that need work are the HAVE_DECL_* and
HAVE_RAW_DECL_*, is that right?

Re: syncing Emacs from sources maintained elsewhere

[Ralf Wildenhues]

* Paul Eggert wrote on Sun, Jan 23, 2011 at 09:38:58PM CET:
> On 01/23/2011 04:39 AM, Eli Zaretskii wrote:
> 
> >  . Why are PACKAGE and VERSION needed, and where are they used?
> 
> That's another Automake thing.  PACKAGE should be "emacs",
> and VERSION "24.0.50".  VERSION is used in some auxiliary
> programs like lib-src/etags.c.  Emacs doesn't use PACKAGE
> anywhere now, but perhaps it will someday.

You can use the Automake option 'no-define' to avoid these two
being AC_DEFINEd.

Cheers,
Ralf

Re: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/23/11 20:08, Eli Zaretskii wrote:
> So the only macros that need work are the HAVE_DECL_* and
> HAVE_RAW_DECL_*, is that right?

You don't need to worry about HAVE_RAW_DECL_* any more;
I recently added some stuff to gnulib to make them go away and
they are no longer in the Emacs trunk.

You do need to worry about HAVE_DECL_*, yes.  Some
of these symbols has been in config.in for quite
some time, but gnulib added some more.

I also suggest looking at HAVE_ATTRIBUTE_ALIGNED,
HAVE_C99_STRTOLD, HAVE_LOCALTIME_R, HAVE_WCHAR_T,
inline, and restrict.

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> Date: Mon, 24 Jan 2011 15:48:30 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org, bug-gnulib@gnu.org
> 
> I also suggest looking at HAVE_ATTRIBUTE_ALIGNED,
> HAVE_C99_STRTOLD, HAVE_LOCALTIME_R, HAVE_WCHAR_T,
> inline, and restrict.

Sure.  I didn't ask about them because their meaning is clear.

Thanks.

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> Date: Mon, 24 Jan 2011 15:48:30 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org, bug-gnulib@gnu.org
> 
> You do need to worry about HAVE_DECL_*, yes.  Some
> of these symbols has been in config.in for quite
> some time, but gnulib added some more.
> 
> I also suggest looking at HAVE_ATTRIBUTE_ALIGNED,
> HAVE_C99_STRTOLD, HAVE_LOCALTIME_R, HAVE_WCHAR_T,
> inline, and restrict.

A few more questions, if I may:

  . Is it true that time_r.c is needed only by mktime.c?  If so, the
    MinGW build of Emacs would not need to worry about time_r.c, since
    it wasn't compiling in mktime.c before the gnulib sync -- is that
    right?

  . Is it true that stddef.in.h, unistd.in.h, and time.in.h are needed
    only on systems which have "issues" with the corresponding
    standard headers?  If so, is it okay to compile gnulib sources in
    lib/ without editing these 3 into the corresponding *.h files?

TIA

Re: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/26/2011 07:43 AM, Eli Zaretskii wrote:

>   . Is it true that time_r.c is needed only by mktime.c?

Yes, for now, but once I add the strftime module, time_r.c will also be needed
by strftime.c, and in that case MinGW will definitely need to worry about
time_r.c.

strftime is quite likely to be added.  I've already coded it up and tested
it, and it works fine on POSIXy platforms.  I plan to add it to Emacs
soon.  Once it's in, Emacs's format-time-string function can start supporting
higher-resolution time stamps.

>   . Is it true that stddef.in.h, unistd.in.h, and time.in.h are needed
>     only on systems which have "issues" with the corresponding
>     standard headers?

The "issues" are either with the headers, or with the implementations of
functions declared by the headers.

>     is it okay to compile gnulib sources in
>     lib/ without editing these 3 into the corresponding *.h files?

If the MinGW headers and implementations are good enough, you should
be OK without the .h files.  I'd be surprised if that were true, though.

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> Date: Thu, 27 Jan 2011 01:22:42 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org, bug-gnulib@gnu.org
> 
> On 01/26/2011 07:43 AM, Eli Zaretskii wrote:
> 
> >   . Is it true that time_r.c is needed only by mktime.c?
> 
> Yes, for now, but once I add the strftime module, time_r.c will also be needed
> by strftime.c, and in that case MinGW will definitely need to worry about
> time_r.c.
> 
> strftime is quite likely to be added.  I've already coded it up and tested
> it, and it works fine on POSIXy platforms.  I plan to add it to Emacs
> soon.

Thanks for the heads-up.  Does gnulib's strftime support MinGW?

> Once it's in, Emacs's format-time-string function can start supporting
> higher-resolution time stamps.

Is this enabled for MinGW as well?

> >   . Is it true that stddef.in.h, unistd.in.h, and time.in.h are needed
> >     only on systems which have "issues" with the corresponding
> >     standard headers?
> 
> The "issues" are either with the headers, or with the implementations of
> functions declared by the headers.
> 
> >     is it okay to compile gnulib sources in
> >     lib/ without editing these 3 into the corresponding *.h files?
> 
> If the MinGW headers and implementations are good enough, you should
> be OK without the .h files.  I'd be surprised if that were true, though.

Where can I find some docs regarding what is considered to be "good
enough"?

Thanks.

Re: syncing Emacs from sources maintained elsewhere

[Bruno Haible]

Eli Zaretskii asked:
> > If the MinGW headers and implementations are good enough, you should
> > be OK without the .h files.  I'd be surprised if that were true, though.
> 
> Where can I find some docs regarding what is considered to be "good
> enough"?

You find detailed information about the particular portability problems
encountered on various systems and worked around (or not) by gnulib
in the gnulib documentation
  <http://www.gnu.org/software/gnulib/manual/html_node/index.html>
especially in the chapters
  7 ISO C and POSIX Header File Substitutes
  8 ISO C and POSIX Function Substitutes
  9 Past POSIX Function Substitutes
  10 Glibc Header File Substitutes
  11 Glibc Function Substitutes

See in particular
  <http://www.gnu.org/software/gnulib/manual/html_node/stddef_002eh.html>
  <http://www.gnu.org/software/gnulib/manual/html_node/unistd_002eh.html>
  <http://www.gnu.org/software/gnulib/manual/html_node/time_002eh.html>

Bruno

gnulib strftime, Emacs, and nanosecond-resolution time stamps

[Paul Eggert]

[Renaming Subject: line from "Re: syncing Emacs from sources maintained elsewhere"]:

On 01/27/11 01:55, Eli Zaretskii wrote:

> Does gnulib's strftime support MinGW?

I expect so, yes.

>> Once it's in, Emacs's format-time-string function can start supporting
>> higher-resolution time stamps.
> 
> Is this enabled for MinGW as well?

Yes, that's pretty much the same code in strftime,
regardless of platform.

There is another issue here: Emacs currently supports
time stamp resolution only to the nearest microsecond.
Gnulib supports nanosecond resolution, which will go
unused inside Emacs's format-time-string function at first.

At some point Emacs can be improved to support
nanosecond-resolution time stamps, but that is
a different task.

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Date: Thu, 27 Jan 2011 11:29:36 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>,
>  emacs-devel@gnu.org
> 
>   <http://www.gnu.org/software/gnulib/manual/html_node/index.html>
> especially in the chapters
>   7 ISO C and POSIX Header File Substitutes
>   8 ISO C and POSIX Function Substitutes
>   9 Past POSIX Function Substitutes
>   10 Glibc Header File Substitutes
>   11 Glibc Function Substitutes
> 
> See in particular
>   <http://www.gnu.org/software/gnulib/manual/html_node/stddef_002eh.html>
>   <http://www.gnu.org/software/gnulib/manual/html_node/unistd_002eh.html>
>   <http://www.gnu.org/software/gnulib/manual/html_node/time_002eh.html>

Thanks for the pointers.

After looking through the documentation, the *.in.h files imported
into Emacs, the headers used by the Emacs w32 build, and the source
files that use them, I concluded that only getopt.in.h should be used
by the Windows build.  The other 3 *.in.h files are not needed at this
time, for the following reasons:

  . The problems with stddef.h and time.h mentioned in the gnulib docs
    do not exist on the reasonably current Windows installations.

  . unistd.h that comes with the C library is not used at all by the
    Windows build of Emacs.  There's a fake (empty) unistd.h in the
    nt/inc directory, with a comment saying that everything that's
    needed is already defined by config.h on Windows.  So if something
    that belongs to unistd.h is missing in the Windows build, I will
    fix that in the Windows config.h.

These conclusions are still largely theoretical, as I just now start
with implementing them, but I'd appreciate comments on them, thanks in
advance.

P.S.  The reason I'd like to minimize the number of gnulib replacement
headers used by the Windows build is that they use #include_next to
include the corresponding system header.  #include_next is a GCC
extension, so it will only work in the MinGW build.  The Windows build
of Emacs currently still supports the MSVC compiler as an alternative.
While the number of users who actually compile with MSVC is very small
(I only know about one, Fabrice Popineau, who recently contributed a
few patches), I don't want to drop that support unless strictly
necessary.

Thanks again for the helpful explanations.

Re: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/28/2011 02:09 AM, Eli Zaretskii wrote:
> The reason I'd like to minimize the number of gnulib replacement
> headers used by the Windows build is that they use #include_next to
> include the corresponding system header.

Minimizing use is good, but when that isn't possible I hope you don't
need to worry about #include_next.  Gnulib uses #include_next only
on compilers that support #include_next, and uses plain #include
(to an absolute file name) otherwise.

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> Date: Fri, 28 Jan 2011 13:06:21 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Bruno Haible <bruno@clisp.org>, bug-gnulib@gnu.org, 
>  emacs-devel@gnu.org
> 
> Gnulib uses #include_next only on compilers that support
> #include_next, and uses plain #include (to an absolute file name)
> otherwise.

Yes, I saw that.  But I don't see how I can use that trick in this
case.  Unlike gnulib, which does this for the machine where the
software is built, I need to produce a getopt.h file that will work on
any machine.  And since there's no standard place to install system
headers on Windows machines, I don't see what absolute file name I
could possibly use.  Maybe I'm missing something.

Re: syncing Emacs from sources maintained elsewhere

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On 01/28/2011 03:36 PM, Eli Zaretskii wrote:
>> Date: Fri, 28 Jan 2011 13:06:21 -0800
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> CC: Bruno Haible <bruno@clisp.org>, bug-gnulib@gnu.org, 
>>  emacs-devel@gnu.org
>>
>> Gnulib uses #include_next only on compilers that support
>> #include_next, and uses plain #include (to an absolute file name)
>> otherwise.
> 
> Yes, I saw that.  But I don't see how I can use that trick in this
> case.  Unlike gnulib, which does this for the machine where the
> software is built, I need to produce a getopt.h file that will work on
> any machine.  And since there's no standard place to install system
> headers on Windows machines, I don't see what absolute file name I
> could possibly use.  Maybe I'm missing something.

Can you assume that emacs will always be built with gcc on Windows, or
are there people that insist on building with a non-free compiler?
#include_next is supported by gcc, so the question boils down to one of
how many compilers you are trying to support (and whether those other
compilers also have either #include_next or something else that
functions the same and can still be #ifdef/#Pragma'd into the header).

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> Date: Fri, 28 Jan 2011 15:40:08 -0700
> From: Eric Blake <eblake@redhat.com>
> CC: Paul Eggert <eggert@cs.ucla.edu>, bug-gnulib@gnu.org, bruno@clisp.org,
>         emacs-devel@gnu.org
> 
> Can you assume that emacs will always be built with gcc on Windows, or
> are there people that insist on building with a non-free compiler?

If I could assume GCC, the problem wouldn't have existed.  There are a
couple of contributors (one of them I mentioned in my previous mail)
who still use MSVC.  For now, I don't want to drop MSVC support, which
is why I want to avoid any *.in.h files that require include_next on
Windows.  Of course, if using include_next will become a necessity
(e.g., when gnulib's strftime is imported to Emacs, as Paul promised),
and MSVC users won't be able to suggest something to replace it, then
we will have no choice but drop MSVC support.

> #include_next is supported by gcc, so the question boils down to one of
> how many compilers you are trying to support (and whether those other
> compilers also have either #include_next or something else that
> functions the same and can still be #ifdef/#Pragma'd into the header).

I searched on the Internet and didn't find any MSVC equivalent of
include_next, but maybe I missed something.

Re: syncing Emacs from sources maintained elsewhere

[Simon Josefsson]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 28 Jan 2011 15:40:08 -0700
>> From: Eric Blake <eblake@redhat.com>
>> CC: Paul Eggert <eggert@cs.ucla.edu>, bug-gnulib@gnu.org, bruno@clisp.org,
>>         emacs-devel@gnu.org
>> 
>> Can you assume that emacs will always be built with gcc on Windows, or
>> are there people that insist on building with a non-free compiler?
>
> If I could assume GCC, the problem wouldn't have existed.  There are a
> couple of contributors (one of them I mentioned in my previous mail)
> who still use MSVC.  For now, I don't want to drop MSVC support, which
> is why I want to avoid any *.in.h files that require include_next on
> Windows.  Of course, if using include_next will become a necessity
> (e.g., when gnulib's strftime is imported to Emacs, as Paul promised),
> and MSVC users won't be able to suggest something to replace it, then
> we will have no choice but drop MSVC support.
>
>> #include_next is supported by gcc, so the question boils down to one of
>> how many compilers you are trying to support (and whether those other
>> compilers also have either #include_next or something else that
>> functions the same and can still be #ifdef/#Pragma'd into the header).
>
> I searched on the Internet and didn't find any MSVC equivalent of
> include_next, but maybe I missed something.

Maybe gnulib's posix library could be used here?  I.e., ask MSVC users
to install that first, so that the system has proper getopt.h etc.

Btw, in Libidn I ship a win32/ sub-directory that has MSVC project files
and hand-written header files (e.g., stdbool.h, unistd.h) because I
could never get gnulib and MSVC to co-exist.  I find this approach saves
me time: all the MSVC stuff is compartmentalized into a special
directory, and because it is MSVC specific it can use whatever ugly
hacks necessary to get things to work.  It also allows MSVC users to
maintain the content of that directory themselves.  In some projects I
also ship Windows specific replacement code in that directory (maybe it
was asprintf?  I don't recall and can't find it now).

I wish that gnulib could support MSVC but it seems like a significant
uphill battle from where gnulib is today, to the extent that I'm not
sure it is worth it compared to a win32/ directory.

(I now realize that msvc/ would have been a more appropriate directory
name.)

/Simon

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> Date: Sun, 23 Jan 2011 12:38:58 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org, bug-gnulib <bug-gnulib@gnu.org>
> 
> >  . Why are PACKAGE and VERSION needed, and where are they used?
> 
> That's another Automake thing.  PACKAGE should be "emacs",
> and VERSION "24.0.50".  VERSION is used in some auxiliary
> programs like lib-src/etags.c.  Emacs doesn't use PACKAGE
> anywhere now, but perhaps it will someday.

Looks like introduction of VERSION into config.in might warrant a
suitable change in admin/admin.el, and perhaps also in src/emacs.c.
Until now, VERSION for etags.c etc. was determined by the `version'
Make variable in lib-src/Makefile.in, which was set by the configure
script by editing emacs.c with Sed.  I see a warning in the current
configure script about mismatch between `version' gleaned from emacs.c
and VERSION set by the configure script itself, but perhaps we should
simply use VERSION set by configure.

For now, I added VERSION to nt/config.nt, but ifdef'ed it away,
pending the decision regarding use of VERSION in config.h.

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> From: Simon Josefsson <simon@josefsson.org>
> Cc: Eric Blake <eblake@redhat.com>, bruno@clisp.org, eggert@cs.ucla.edu,
>         bug-gnulib@gnu.org, emacs-devel@gnu.org
> Date: Sat, 29 Jan 2011 10:32:32 +0100
> 
> Maybe gnulib's posix library could be used here?  I.e., ask MSVC users
> to install that first, so that the system has proper getopt.h etc.
> 
> Btw, in Libidn I ship a win32/ sub-directory that has MSVC project files
> and hand-written header files (e.g., stdbool.h, unistd.h) because I
> could never get gnulib and MSVC to co-exist.

Emacs uses a combination of these two techniques, but until now we
managed to have almost the same workarounds and headers for both MinGW
and MSVC.  E.g., unistd.h is not used at all (although MinGW does have
it); instead, all the necessary stuff is defined in the
Windows-specific config.h file.  There's a Windows-specific nt/
subdirectory where we put headers and source files that define
suitable replacements for missing Posix headers and functions.

It would make sense to have MSVC-specific replacements there as well,
once it becomes impossible to keep it and MinGW together.

Thanks for the feedback.

Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Tue, 18 Jan 2011 10:11:17 +0000
> 
> The changes to update gnulib break the Windows build, which will no
> longer bootstrap. It seems that the new lib dir needs a makefile.win-in
> and some work on the build scripts similar to the old lib-src dir.

Should be fixed now, although I didn't yet have time to try a
bootstrap.

Re: syncing Emacs from sources maintained elsewhere

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> The changes to update gnulib break the Windows build, which will no
>> longer bootstrap. It seems that the new lib dir needs a makefile.win-in
>> and some work on the build scripts similar to the old lib-src dir.
>
> Should be fixed now, although I didn't yet have time to try a
> bootstrap.

Great news, thanks!

Re: syncing Emacs from sources maintained elsewhere

[Paul Eggert]

On 01/29/2011 02:04 AM, Eli Zaretskii wrote:

> Looks like introduction of VERSION into config.in might warrant a
> suitable change in admin/admin.el, and perhaps also in src/emacs.c.

Yes, that makes sense.  I committed this to the trunk
(automatically-generated changes omitted):

=== modified file 'ChangeLog'
--- ChangeLog	2011-01-30 23:34:18 +0000
+++ ChangeLog	2011-01-31 08:13:25 +0000
@@ -1,3 +1,11 @@
+2011-01-31  Paul Eggert  <eggert@cs.ucla.edu>
+
+	src/emacs.c now gets version number from configure.in
+	* configure.in (version): Set this from $PACKAGE_VERSION,
+	which is set from AC_INIT, rather than scouting through src/emacs.c.
+	* configure: Regenerate.
+	* make-dist (version): Get it from configure.in, not src/emacs.c.
+
 2011-01-30  Paul Eggert  <eggert@cs.ucla.edu>
 
 	strftime: import from gnulib

=== modified file 'admin/ChangeLog'
--- admin/ChangeLog	2011-01-30 23:34:18 +0000
+++ admin/ChangeLog	2011-01-31 08:13:25 +0000
@@ -1,3 +1,10 @@
+2011-01-31  Paul Eggert  <eggert@cs.ucla.edu>
+
+	src/emacs.c now gets version number from configure.in
+	* admin.el (set-version): Don't update src/emacs.c.
+	* quick-install-emacs (VERSION): Get it from configure.in, not from
+	src/emacs.c.
+
 2011-01-30  Paul Eggert  <eggert@cs.ucla.edu>
 
 	strftime: import from gnulib

=== modified file 'admin/admin.el'
--- admin/admin.el	2011-01-25 04:08:28 +0000
+++ admin/admin.el	2011-01-31 08:13:25 +0000
@@ -59,9 +59,6 @@
   (interactive "DEmacs root directory: \nsVersion number: ")
   (unless (file-exists-p (expand-file-name "src/emacs.c" root))
     (error "%s doesn't seem to be the root of an Emacs source tree" root))
-  (set-version-in-file root "src/emacs.c" version
-		       (rx (and "emacs_version" (0+ (not (in ?\")))
-				?\" (submatch (1+ (not (in ?\")))) ?\")))
   (set-version-in-file root "README" version
 		       (rx (and "version" (1+ space)
 				(submatch (1+ (in "0-9."))))))

=== modified file 'admin/quick-install-emacs'
--- admin/quick-install-emacs	2011-01-25 04:08:28 +0000
+++ admin/quick-install-emacs	2011-01-31 08:13:25 +0000
@@ -170,8 +170,10 @@
 test x"$prefix" = x && { prefix="`get_config_var prefix`" || exit 4 ; }
 test x"$ARCH" = x && { ARCH="`get_config_var host`" || exit 4 ; }
 
-VERSION=`grep 'char emacs_version' $SRC/src/emacs.c \
-         | sed -e 's/^[^"]*"\([^"]*\)".*$/\1/'`
+VERSION=`
+  sed -n 's/^AC_INIT(emacs,[	 ]*\([^	 )]*\).*/\1/p' <$SRC/configure.in
+` || exit 4
+test -n "$VERSION" || { echo >&2 "$me: no version in configure.in"; exit 4; }
 
 DST_SHARE="$prefix/share/emacs/$VERSION"
 DST_BIN="$prefix/bin"

=== modified file 'configure.in'
--- configure.in	2011-01-30 23:34:18 +0000
+++ configure.in	2011-01-31 08:13:25 +0000
@@ -3070,15 +3070,7 @@
    AC_MSG_ERROR([GCC 4.5.0 has problems compiling Emacs; see etc/PROBLEMS'.])
 fi
 
-#### Find out which version of Emacs this is.
-[version=`grep 'const char emacs_version' ${srcdir}/src/emacs.c \
-	 | sed -e 's/^[^"]*"\([^"]*\)".*$/\1/'`]
-if test x"${version}" = x; then
-  AC_MSG_ERROR([can't find current emacs version in `${srcdir}/src/emacs.c'.])
-fi
-if test x"${version}" != x"$PACKAGE_VERSION"; then
-  AC_MSG_WARN([version mismatch between `${srcdir}/configure.in' and `${srcdir}/src/emacs.c'.])
-fi
+version=$PACKAGE_VERSION
 
 ### Specify what sort of things we'll be editing into Makefile and config.h.
 ### Use configuration here uncanonicalized to avoid exceeding size limits.

=== modified file 'lib-src/ChangeLog'
--- lib-src/ChangeLog	2011-01-30 09:17:36 +0000
+++ lib-src/ChangeLog	2011-01-31 08:13:25 +0000
@@ -1,3 +1,8 @@
+2011-01-31  Paul Eggert  <eggert@cs.ucla.edu>
+
+	src/emacs.c now gets version number from configure.in
+	* ebrowse.c: Adjust comment to say that.
+
 2011-01-30  Jim Meyering  <meyering@redhat.com>
 
 	make-docfile: don't corrupt heap for an invalid .elc file

=== modified file 'lib-src/ebrowse.c'
--- lib-src/ebrowse.c	2011-01-25 04:08:28 +0000
+++ lib-src/ebrowse.c	2011-01-31 08:13:25 +0000
@@ -3565,7 +3565,7 @@
 
 
 /* Display version and copyright info.  The VERSION macro is set
-   from the Makefile and contains the Emacs version.  */
+   from config.h and contains the Emacs version.  */
 
 #ifndef VERSION
 # define VERSION "21"
@@ -3812,7 +3812,7 @@
 	      yyerror ("error getting size of file `%s'", out_filename);
 	      exit (EXIT_FAILURE);
 	    }
-	  
+
 	  else if (rc == 0)
 	    {
 	      yyerror ("file `%s' is empty", out_filename);

=== modified file 'make-dist'
--- make-dist	2011-01-25 04:08:28 +0000
+++ make-dist	2011-01-31 08:13:25 +0000
@@ -146,7 +146,9 @@
 fi
 
 ### Find out which version of Emacs this is.
-version=`sed -n '/char emacs_version/ s/^[^"]*"\([^"]*\)".*$/\1/p' src/emacs.c`
+version=`
+  sed -n 's/^AC_INIT(emacs,[	 ]*\([^	 )]*\).*/\1/p' <configure.in
+` || version=
 if [ ! "${version}" ]; then
   echo "${progname}: can't find current Emacs version in \`./src/emacs.c'" >&2
   exit 1

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2011-01-31 07:34:45 +0000
+++ src/ChangeLog	2011-01-31 08:14:12 +0000
@@ -1,3 +1,9 @@
+2011-01-31  Paul Eggert  <eggert@cs.ucla.edu>
+
+	src/emacs.c now gets version number from configure.in
+	* emacs.c (emacs_version): Set to VERSION so that it
+	is determined automatically from ../configure.in.
+
 2011-01-31  Jim Meyering  <meyering@redhat.com>
 
 	* charset.c (load_charset_map): Don't deref NULL on failed malloc.

=== modified file 'src/emacs.c'
--- src/emacs.c	2011-01-30 22:17:44 +0000
+++ src/emacs.c	2011-01-31 08:13:25 +0000
@@ -88,9 +88,7 @@
 #endif
 #endif
 
-/* If you change the following line, remember to update
-   msdos/mainmake.v2 which gleans the Emacs version from it!  */
-static const char emacs_version[] = "24.0.50";
+static const char emacs_version[] = VERSION;
 static const char emacs_copyright[] = "Copyright (C) 2011 Free Software Foundation, Inc.";
 
 /* Make these values available in GDB, which doesn't see macros.  */