* syncing Emacs from sources maintained elsewhere
@ 2011-01-11 0:50 Paul Eggert
2011-01-11 1:38 ` Miles Bader
2011-01-17 20:37 ` Paul Eggert
0 siblings, 2 replies; 64+ messages in thread
From: Paul Eggert @ 2011-01-11 0:50 UTC (permalink / raw)
To: emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: syncing Emacs from sources maintained elsewhere
2011-01-11 0:50 syncing Emacs from sources maintained elsewhere Paul Eggert
@ 2011-01-11 1:38 ` Miles Bader
2011-01-11 4:39 ` Paul Eggert
2011-01-17 20:37 ` Paul Eggert
1 sibling, 1 reply; 64+ messages in thread
From: Miles Bader @ 2011-01-11 1:38 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-11 0:50 syncing Emacs from sources maintained elsewhere Paul Eggert
2011-01-11 1:38 ` Miles Bader
@ 2011-01-17 20:37 ` Paul Eggert
2011-01-17 21:35 ` Stefan Monnier
2011-01-18 10:11 ` Andy Moreton
1 sibling, 2 replies; 64+ messages in thread
From: Paul Eggert @ 2011-01-17 20:37 UTC (permalink / raw)
To: emacs-devel; +Cc: bug-gnulib
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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-17 20:37 ` Paul Eggert
@ 2011-01-17 21:35 ` Stefan Monnier
2011-01-17 22:12 ` Paul Eggert
2011-01-18 10:11 ` Andy Moreton
1 sibling, 1 reply; 64+ messages in thread
From: Stefan Monnier @ 2011-01-17 21:35 UTC (permalink / raw)
To: Paul Eggert; +Cc: bug-gnulib, emacs-devel
> 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
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: syncing Emacs from sources maintained elsewhere
2011-01-17 21:35 ` Stefan Monnier
@ 2011-01-17 22:12 ` Paul Eggert
0 siblings, 0 replies; 64+ messages in thread
From: Paul Eggert @ 2011-01-17 22:12 UTC (permalink / raw)
To: Stefan Monnier; +Cc: bug-gnulib, emacs-devel
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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-17 20:37 ` Paul Eggert
2011-01-17 21:35 ` Stefan Monnier
@ 2011-01-18 10:11 ` Andy Moreton
2011-01-18 15:20 ` Eli Zaretskii
2011-01-29 12:53 ` Eli Zaretskii
1 sibling, 2 replies; 64+ messages in thread
From: Andy Moreton @ 2011-01-18 10:11 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: syncing Emacs from sources maintained elsewhere
2011-01-18 10:11 ` Andy Moreton
@ 2011-01-18 15:20 ` Eli Zaretskii
2011-01-18 18:13 ` Paul Eggert
2011-01-29 12:53 ` Eli Zaretskii
1 sibling, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-18 15:20 UTC (permalink / raw)
To: Andy Moreton; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-18 15:20 ` Eli Zaretskii
@ 2011-01-18 18:13 ` Paul Eggert
2011-01-18 22:57 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 64+ messages in thread
From: Paul Eggert @ 2011-01-18 18:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andy Moreton, emacs-devel
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").
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: syncing Emacs from sources maintained elsewhere
2011-01-18 18:13 ` Paul Eggert
@ 2011-01-18 22:57 ` Eli Zaretskii
2011-01-19 0:36 ` Paul Eggert
2011-01-19 1:20 ` Glenn Morris
2011-01-23 12:39 ` Eli Zaretskii
2 siblings, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-18 22:57 UTC (permalink / raw)
To: Paul Eggert; +Cc: andrewjmoreton, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-18 22:57 ` Eli Zaretskii
@ 2011-01-19 0:36 ` Paul Eggert
2011-01-19 15:03 ` Eli Zaretskii
0 siblings, 1 reply; 64+ messages in thread
From: Paul Eggert @ 2011-01-19 0:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: andrewjmoreton, emacs-devel
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
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: syncing Emacs from sources maintained elsewhere
2011-01-19 0:36 ` Paul Eggert
@ 2011-01-19 15:03 ` Eli Zaretskii
0 siblings, 0 replies; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-19 15:03 UTC (permalink / raw)
To: Paul Eggert; +Cc: andrewjmoreton, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-18 18:13 ` Paul Eggert
2011-01-18 22:57 ` Eli Zaretskii
@ 2011-01-19 1:20 ` Glenn Morris
2011-01-19 6:04 ` bug#7859: " Paul Eggert
` (2 more replies)
2011-01-23 12:39 ` Eli Zaretskii
2 siblings, 3 replies; 64+ messages in thread
From: Glenn Morris @ 2011-01-19 1:20 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
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'
^ permalink raw reply [flat|nested] 64+ messages in thread* bug#7859: syncing Emacs from sources maintained elsewhere
2011-01-19 1:20 ` Glenn Morris
@ 2011-01-19 6:04 ` Paul Eggert
2011-01-19 6:04 ` Paul Eggert
2011-01-19 6:04 ` Paul Eggert
2 siblings, 0 replies; 64+ messages in thread
From: Paul Eggert @ 2011-01-19 6:04 UTC (permalink / raw)
To: Glenn Morris; +Cc: 7859, bug-gnulib, 7856, emacs-devel
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.
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: syncing Emacs from sources maintained elsewhere
2011-01-19 1:20 ` Glenn Morris
2011-01-19 6:04 ` bug#7859: " Paul Eggert
@ 2011-01-19 6:04 ` Paul Eggert
[not found] ` <4D368D16.7020702@swipnet.se>
2011-01-19 6:04 ` Paul Eggert
2 siblings, 1 reply; 64+ messages in thread
From: Paul Eggert @ 2011-01-19 6:04 UTC (permalink / raw)
To: Glenn Morris; +Cc: 7859, bug-gnulib, 7856, emacs-devel
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.
^ permalink raw reply [flat|nested] 64+ messages in thread* bug#7856: syncing Emacs from sources maintained elsewhere
2011-01-19 1:20 ` Glenn Morris
2011-01-19 6:04 ` bug#7859: " Paul Eggert
2011-01-19 6:04 ` Paul Eggert
@ 2011-01-19 6:04 ` Paul Eggert
2 siblings, 0 replies; 64+ messages in thread
From: Paul Eggert @ 2011-01-19 6:04 UTC (permalink / raw)
To: Glenn Morris; +Cc: 7859, bug-gnulib, 7856, emacs-devel
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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-18 18:13 ` Paul Eggert
2011-01-18 22:57 ` Eli Zaretskii
2011-01-19 1:20 ` Glenn Morris
@ 2011-01-23 12:39 ` Eli Zaretskii
2011-01-23 20:38 ` Paul Eggert
2 siblings, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-23 12:39 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-23 12:39 ` Eli Zaretskii
@ 2011-01-23 20:38 ` Paul Eggert
2011-01-24 4:08 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 64+ messages in thread
From: Paul Eggert @ 2011-01-23 20:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: bug-gnulib, emacs-devel
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.
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: syncing Emacs from sources maintained elsewhere
2011-01-23 20:38 ` Paul Eggert
@ 2011-01-24 4:08 ` Eli Zaretskii
2011-01-24 23:48 ` Paul Eggert
2011-01-24 6:18 ` syncing Emacs from sources maintained elsewhere Ralf Wildenhues
2011-01-29 10:04 ` Eli Zaretskii
2 siblings, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-24 4:08 UTC (permalink / raw)
To: Paul Eggert; +Cc: bug-gnulib, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-24 4:08 ` Eli Zaretskii
@ 2011-01-24 23:48 ` Paul Eggert
2011-01-25 4:02 ` Eli Zaretskii
2011-01-26 15:43 ` Eli Zaretskii
0 siblings, 2 replies; 64+ messages in thread
From: Paul Eggert @ 2011-01-24 23:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: bug-gnulib, emacs-devel
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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-24 23:48 ` Paul Eggert
@ 2011-01-25 4:02 ` Eli Zaretskii
2011-01-26 15:43 ` Eli Zaretskii
1 sibling, 0 replies; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-25 4:02 UTC (permalink / raw)
To: Paul Eggert; +Cc: bug-gnulib, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-24 23:48 ` Paul Eggert
2011-01-25 4:02 ` Eli Zaretskii
@ 2011-01-26 15:43 ` Eli Zaretskii
2011-01-27 9:22 ` Paul Eggert
1 sibling, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-26 15:43 UTC (permalink / raw)
To: Paul Eggert; +Cc: bug-gnulib, emacs-devel
> 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
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: syncing Emacs from sources maintained elsewhere
2011-01-26 15:43 ` Eli Zaretskii
@ 2011-01-27 9:22 ` Paul Eggert
2011-01-27 9:55 ` Eli Zaretskii
0 siblings, 1 reply; 64+ messages in thread
From: Paul Eggert @ 2011-01-27 9:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: bug-gnulib, emacs-devel
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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-27 9:22 ` Paul Eggert
@ 2011-01-27 9:55 ` Eli Zaretskii
2011-01-27 10:29 ` Bruno Haible
2011-01-27 20:50 ` gnulib strftime, Emacs, and nanosecond-resolution time stamps Paul Eggert
0 siblings, 2 replies; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-27 9:55 UTC (permalink / raw)
To: Paul Eggert; +Cc: bug-gnulib, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-27 9:55 ` Eli Zaretskii
@ 2011-01-27 10:29 ` Bruno Haible
2011-01-28 10:09 ` Eli Zaretskii
2011-01-27 20:50 ` gnulib strftime, Emacs, and nanosecond-resolution time stamps Paul Eggert
1 sibling, 1 reply; 64+ messages in thread
From: Bruno Haible @ 2011-01-27 10:29 UTC (permalink / raw)
To: bug-gnulib, Eli Zaretskii; +Cc: Paul Eggert, emacs-devel
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-27 10:29 ` Bruno Haible
@ 2011-01-28 10:09 ` Eli Zaretskii
2011-01-28 21:06 ` Paul Eggert
0 siblings, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-28 10:09 UTC (permalink / raw)
To: Bruno Haible; +Cc: eggert, bug-gnulib, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: syncing Emacs from sources maintained elsewhere
2011-01-28 10:09 ` Eli Zaretskii
@ 2011-01-28 21:06 ` Paul Eggert
2011-01-28 22:36 ` Eli Zaretskii
0 siblings, 1 reply; 64+ messages in thread
From: Paul Eggert @ 2011-01-28 21:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: bug-gnulib, Bruno Haible, emacs-devel
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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-28 21:06 ` Paul Eggert
@ 2011-01-28 22:36 ` Eli Zaretskii
2011-01-28 22:40 ` Eric Blake
0 siblings, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-28 22:36 UTC (permalink / raw)
To: Paul Eggert; +Cc: bug-gnulib, bruno, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-28 22:36 ` Eli Zaretskii
@ 2011-01-28 22:40 ` Eric Blake
2011-01-29 8:48 ` Eli Zaretskii
0 siblings, 1 reply; 64+ messages in thread
From: Eric Blake @ 2011-01-28 22:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: bruno, Paul Eggert, bug-gnulib, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-28 22:40 ` Eric Blake
@ 2011-01-29 8:48 ` Eli Zaretskii
2011-01-29 9:32 ` Simon Josefsson
0 siblings, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-29 8:48 UTC (permalink / raw)
To: Eric Blake; +Cc: bruno, eggert, bug-gnulib, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-29 8:48 ` Eli Zaretskii
@ 2011-01-29 9:32 ` Simon Josefsson
2011-01-29 10:24 ` Eli Zaretskii
0 siblings, 1 reply; 64+ messages in thread
From: Simon Josefsson @ 2011-01-29 9:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: bug-gnulib, bruno, eggert, Eric Blake, emacs-devel
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-29 9:32 ` Simon Josefsson
@ 2011-01-29 10:24 ` Eli Zaretskii
0 siblings, 0 replies; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-29 10:24 UTC (permalink / raw)
To: Simon Josefsson; +Cc: bug-gnulib, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* gnulib strftime, Emacs, and nanosecond-resolution time stamps
2011-01-27 9:55 ` Eli Zaretskii
2011-01-27 10:29 ` Bruno Haible
@ 2011-01-27 20:50 ` Paul Eggert
1 sibling, 0 replies; 64+ messages in thread
From: Paul Eggert @ 2011-01-27 20:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: bug-gnulib, emacs-devel
[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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-23 20:38 ` Paul Eggert
2011-01-24 4:08 ` Eli Zaretskii
@ 2011-01-24 6:18 ` Ralf Wildenhues
2011-01-29 10:04 ` Eli Zaretskii
2 siblings, 0 replies; 64+ messages in thread
From: Ralf Wildenhues @ 2011-01-24 6:18 UTC (permalink / raw)
To: Paul Eggert; +Cc: Eli Zaretskii, bug-gnulib, emacs-devel
* 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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-23 20:38 ` Paul Eggert
2011-01-24 4:08 ` Eli Zaretskii
2011-01-24 6:18 ` syncing Emacs from sources maintained elsewhere Ralf Wildenhues
@ 2011-01-29 10:04 ` Eli Zaretskii
2011-01-31 8:19 ` Paul Eggert
2 siblings, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-29 10:04 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-29 10:04 ` Eli Zaretskii
@ 2011-01-31 8:19 ` Paul Eggert
0 siblings, 0 replies; 64+ messages in thread
From: Paul Eggert @ 2011-01-31 8:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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. */
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-18 10:11 ` Andy Moreton
2011-01-18 15:20 ` Eli Zaretskii
@ 2011-01-29 12:53 ` Eli Zaretskii
2011-01-29 15:46 ` Chong Yidong
1 sibling, 1 reply; 64+ messages in thread
From: Eli Zaretskii @ 2011-01-29 12:53 UTC (permalink / raw)
To: Andy Moreton; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: syncing Emacs from sources maintained elsewhere
2011-01-29 12:53 ` Eli Zaretskii
@ 2011-01-29 15:46 ` Chong Yidong
0 siblings, 0 replies; 64+ messages in thread
From: Chong Yidong @ 2011-01-29 15:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andy Moreton, emacs-devel
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!
^ permalink raw reply [flat|nested] 64+ messages in thread
end of thread, other threads:[~2011-01-31 8:19 UTC | newest]
Thread overview: 64+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-11 0:50 syncing Emacs from sources maintained elsewhere Paul Eggert
2011-01-11 1:38 ` Miles Bader
2011-01-11 4:39 ` Paul Eggert
2011-01-17 20:37 ` Paul Eggert
2011-01-17 21:35 ` Stefan Monnier
2011-01-17 22:12 ` Paul Eggert
2011-01-18 10:11 ` Andy Moreton
2011-01-18 15:20 ` Eli Zaretskii
2011-01-18 18:13 ` Paul Eggert
2011-01-18 22:57 ` Eli Zaretskii
2011-01-19 0:36 ` Paul Eggert
2011-01-19 15:03 ` Eli Zaretskii
2011-01-19 1:20 ` Glenn Morris
2011-01-19 6:04 ` bug#7859: " Paul Eggert
2011-01-19 6:04 ` Paul Eggert
[not found] ` <4D368D16.7020702@swipnet.se>
2011-01-19 9:00 ` Glenn Morris
2011-01-19 10:38 ` bug#7859: " Paul Eggert
2011-01-19 10:38 ` Paul Eggert
2011-01-19 15:54 ` bug#7856: bug#7859: " Jan Djärv
2011-01-19 15:54 ` Jan Djärv
2011-01-19 15:54 ` Jan Djärv
2011-01-19 23:44 ` Paul Eggert
2011-01-20 0:21 ` Eli Zaretskii
2011-01-20 0:21 ` Eli Zaretskii
2011-01-20 6:45 ` Jan Djärv
2011-01-20 6:45 ` Jan Djärv
2011-01-20 7:51 ` Paul Eggert
2011-01-20 7:51 ` bug#7856: " Paul Eggert
2011-01-20 7:51 ` Paul Eggert
2011-01-20 11:26 ` Jan D.
2011-01-20 11:26 ` bug#7856: " Jan D.
2011-01-20 11:26 ` Jan D.
2011-01-20 6:45 ` bug#7856: " Jan Djärv
2011-01-19 23:44 ` Paul Eggert
2011-01-19 23:44 ` Paul Eggert
2011-01-19 23:49 ` Paul Eggert
2011-01-20 2:30 ` Tom Tromey
2011-01-20 0:27 ` Eric Blake
2011-01-20 0:27 ` Eric Blake
2011-01-20 0:27 ` bug#7856: " Eric Blake
2011-01-19 10:38 ` Paul Eggert
2011-01-19 6:04 ` Paul Eggert
2011-01-23 12:39 ` Eli Zaretskii
2011-01-23 20:38 ` Paul Eggert
2011-01-24 4:08 ` Eli Zaretskii
2011-01-24 23:48 ` Paul Eggert
2011-01-25 4:02 ` Eli Zaretskii
2011-01-26 15:43 ` Eli Zaretskii
2011-01-27 9:22 ` Paul Eggert
2011-01-27 9:55 ` Eli Zaretskii
2011-01-27 10:29 ` Bruno Haible
2011-01-28 10:09 ` Eli Zaretskii
2011-01-28 21:06 ` Paul Eggert
2011-01-28 22:36 ` Eli Zaretskii
2011-01-28 22:40 ` Eric Blake
2011-01-29 8:48 ` Eli Zaretskii
2011-01-29 9:32 ` Simon Josefsson
2011-01-29 10:24 ` Eli Zaretskii
2011-01-27 20:50 ` gnulib strftime, Emacs, and nanosecond-resolution time stamps Paul Eggert
2011-01-24 6:18 ` syncing Emacs from sources maintained elsewhere Ralf Wildenhues
2011-01-29 10:04 ` Eli Zaretskii
2011-01-31 8:19 ` Paul Eggert
2011-01-29 12:53 ` Eli Zaretskii
2011-01-29 15:46 ` Chong Yidong
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.