* Last commit breaks macOS build @ 2017-01-04 10:08 Angelo Graziosi 2017-01-05 3:21 ` Paul Eggert 0 siblings, 1 reply; 21+ messages in thread From: Angelo Graziosi @ 2017-01-04 10:08 UTC (permalink / raw) To: Emacs developers, Paul Eggert This commit: 44c588a25ce231ce05fb535cd6d7162e91214f45 (Port recent autogen.sh changes to Darwin) breaks the build on macOS: ./autogen.sh [...] Your system has the required tools. Interfering nt/gnulib.mk from lib/gnulib.mk ... sed: 46: "This is of m...": command c expects \ followed by text and the 'configure' is not created... Angelo ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-04 10:08 Last commit breaks macOS build Angelo Graziosi @ 2017-01-05 3:21 ` Paul Eggert 2017-01-05 9:30 ` Richard Copley 2017-01-05 16:24 ` Eli Zaretskii 0 siblings, 2 replies; 21+ messages in thread From: Paul Eggert @ 2017-01-05 3:21 UTC (permalink / raw) To: Angelo Graziosi, Emacs developers [-- Attachment #1: Type: text/plain, Size: 538 bytes --] Angelo Graziosi wrote: > Interfering nt/gnulib.mk from lib/gnulib.mk ... Did it really say "Interfering"? :-) > sed: 46: "This is of m...": command c expects \ followed by text > > and the 'configure' is not created... This is caused by our recent attempt to better-automate MS-Windows builds. I fixed one nonportable construct, but evidently there are others. It's time to break out a bigger hammer. Please try the attached patch. I have tested it on Fedora, but not on MS-Windows and so have not installed it yet. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Use-GNU-Make-instead-of-sed-Automake-for-nt-lib.patch --] [-- Type: text/x-diff; name="0001-Use-GNU-Make-instead-of-sed-Automake-for-nt-lib.patch", Size: 10602 bytes --] From d59053569fb37f80487810f6e18da0ac9030a0da Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Wed, 4 Jan 2017 19:13:14 -0800 Subject: [PATCH] Use GNU Make instead of sed+Automake for nt lib Problem reported by Angelo Graziosi. Instead of continuing to hack something in autogen.sh, which is a pain to port and which is a prepass to Automake, this patch uses GNU Make instead, so that there is no need to have anything in autogen.sh and no need for an nt/gnulib.mk file. * .gitignore: Remove nt/gnulib.mk. * Makefile.in (gnulib_mk, $(srcdir)/nt/gnulib.mk): Remove. (AUTOMAKE_INPUTS): Use $(srcdir)/lib/gnulib.mk, not gnulib_mk. * autogen.sh: Do not build nt/gnulib.mk. * configure.ac (GNULIB_MK): Remove. (SYSTEM_TYPE): Subst. (MT): New macro. Subst it. * lib/Makefile.am: Do not include ../nt/gnulib.mk. Use $(SYSTEM_TYPE), not BUILDING_FOR_WINDOWSNT. (libgnu_a_SOURCES_not, EXTRA_libgnu_a_SOURCES_not): New macros. (libgnu_a_SOURCES, EXTRA_libgnu_a_SOURCES) [windows-nt]: Filter out unwanted modules. * make-dist: Omit removed files. * nt/Makefile.in (AM_V_GEN, am__v_GEN_, am__v_GEN_0) (am__v_GEN_1, ${srcdir}/gnulib.mk): Remove. * nt/gnulib-modules-to-delete.cfg: Remove. --- .gitignore | 1 - Makefile.in | 8 +---- autogen.sh | 10 +------ configure.ac | 22 ++++---------- lib/Makefile.am | 19 ++++++++---- make-dist | 2 +- nt/Makefile.in | 10 ------- nt/gnulib-modules-to-delete.cfg | 66 ----------------------------------------- 8 files changed, 23 insertions(+), 115 deletions(-) delete mode 100644 nt/gnulib-modules-to-delete.cfg diff --git a/.gitignore b/.gitignore index e8eb4fd..85c06c9 100644 --- a/.gitignore +++ b/.gitignore @@ -288,6 +288,5 @@ lib/SYS/ /site-lisp/ nt/emacs.rc nt/emacsclient.rc -nt/gnulib.mk src/gdb.ini /var/ diff --git a/Makefile.in b/Makefile.in index b9aaf5b..3cb1f5e 100644 --- a/Makefile.in +++ b/Makefile.in @@ -98,9 +98,6 @@ configuration= ### The nt/ subdirectory gets built only for MinGW NTDIR=@NTDIR@ -### $(srcdir)/nt/gnulib.mk for MinGW, else $(srcdir)/lib/gnulib.mk -gnulib_mk=@GNULIB_MK@ - # 'make' verbosity. AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@ @@ -454,13 +451,10 @@ $(srcdir)/aclocal.m4: cd $(srcdir) && ACLOCAL_PATH='$(ACLOCAL_PATH)' $(ACLOCAL) -I m4 AUTOMAKE_INPUTS = $(srcdir)/aclocal.m4 $(srcdir)/lib/Makefile.am \ - $(gnulib_mk) + $(srcdir)/lib/gnulib.mk $(srcdir)/lib/Makefile.in: $(AUTOMAKE_INPUTS) cd $(srcdir) && $(AUTOMAKE) --gnu -a -c lib/Makefile -$(srcdir)/nt/gnulib.mk: $(srcdir)/lib/Makefile.in - $(MAKE) -C $(srcdir)/nt gnulib.mk - # Regenerate files that this makefile would have made, if this makefile # had been built by Automake. The name 'am--refresh' is for # compatibility with subsidiary Automake-generated makefiles. diff --git a/autogen.sh b/autogen.sh index f6bfde6..7381bc3 100755 --- a/autogen.sh +++ b/autogen.sh @@ -220,17 +220,9 @@ do_git= fi echo 'Your system has the required tools.' - - ## Create nt/gnulib.mk if it doesn't exist, as autoreconf will need it. - if test ! -f nt/gnulib.mk; then - echo 'Inferring nt/gnulib.mk from lib/gnulib.mk ...' - metascript='/^[^#]/s|^.*$|/^## begin *gnulib module &/,/^## end *gnulib module &/c ## gnulib module & removed|' - script=`sed "$metascript" nt/gnulib-modules-to-delete.cfg` || exit - sed "$script" lib/gnulib.mk > nt/gnulib.mk || exit - fi - echo "Running 'autoreconf -fi -I m4' ..." + ## Let autoreconf figure out what, if anything, needs doing. ## Use autoreconf's -f option in case autoreconf itself has changed. autoreconf -fi -I m4 || exit $? diff --git a/configure.ac b/configure.ac index 262f367..7fd4988 100644 --- a/configure.ac +++ b/configure.ac @@ -771,22 +771,6 @@ AC_DEFUN test "x$GCC_TEST_OPTIONS" != x && CC="$CC $GCC_TEST_OPTIONS" fi -dnl This is used in lib/Makefile.am to use nt/gnulib.mk, the -dnl alternative to lib/gnulib.mk, so as to avoid generating header files -dnl that clash with MinGW. -case $opsys in - mingw32 ) - GNULIB_MK='$(srcdir)/nt/gnulib.mk' - ;; - * ) - GNULIB_MK='$(srcdir)/lib/gnulib.mk' - ;; - -esac -AC_SUBST([GNULIB_MK]) - -AM_CONDITIONAL([BUILDING_FOR_WINDOWSNT], [test "x$opsys" = "xmingw32"]) - # Avoid gnulib's tests for -lcrypto, so that there's no static dependency on it. AC_DEFUN([gl_CRYPTO_CHECK]) # Avoid gnulib's tests for HAVE_WORKING_O_NOATIME and HAVE_WORKING_O_NOFOLLOW, @@ -1555,7 +1539,13 @@ AC_DEFUN AC_SUBST(LIB_MATH) AC_DEFINE_UNQUOTED(SYSTEM_TYPE, "$SYSTEM_TYPE", [The type of system you are compiling for; sets 'system-type'.]) +AC_SUBST([SYSTEM_TYPE]) +# The empty (MT) string. +# Use this in Makefile.am before GNU Make conditionals; +# otherwise, Automake gets confused. +MT= +AC_SUBST([MT]) pre_PKG_CONFIG_CFLAGS=$CFLAGS pre_PKG_CONFIG_LIBS=$LIBS diff --git a/lib/Makefile.am b/lib/Makefile.am index e6d90dd..141838c 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -29,13 +29,22 @@ SUFFIXES = AM_CFLAGS = $(PROFILING_CFLAGS) $(GNULIB_WARN_CFLAGS) $(WERROR_CFLAGS) DEFAULT_INCLUDES = -I. -I$(top_srcdir)/lib -I../src -I$(top_srcdir)/src -if BUILDING_FOR_WINDOWSNT -include ../nt/gnulib.mk -else include gnulib.mk -libgnu_a_SOURCES += openat-die.c save-cwd.c -endif +@MT@ifeq ($(SYSTEM_TYPE), windows-nt) +@MT@ libgnu_a_SOURCES_not = \ +@MT@ acl-errno-valid.c acl-internal.c allocator.c \ +@MT@ careadlinkat.c get-permissions.c pipe2.c \ +@MT@ set-permissions.c tempname.c unistd.c +@MT@ libgnu_a_SOURCES := \ +@MT@ $(filter-out $(libgnu_a_SOURCES_not), $(libgnu_a_SOURCES)) +@MT@ EXTRA_libgnu_a_SOURCES_not = \ +@MT@ acl_entries.c dirfd.c fcntl.c mkostemp.c openat-proc.c secure_getenv.c +@MT@ EXTRA_libgnu_a_SOURCES := \ +@MT@ $(filter-out $(EXTRA_libgnu_a_SOURCES_not), $(EXTRA_libgnu_a_SOURCES)) +@MT@else +@MT@ libgnu_a_SOURCES += openat-die.c save-cwd.c +@MT@endif if HYBRID_MALLOC_LIB noinst_LIBRARIES += libegnu.a diff --git a/make-dist b/make-dist index 41203b2..2d1a218 100755 --- a/make-dist +++ b/make-dist @@ -482,7 +482,7 @@ files= (cd nt ln emacs-x86.manifest emacs-x64.manifest ../${tempdir}/nt ln [a-z]*.bat [a-z]*.[ch] ../${tempdir}/nt - ln *.in gnulib.mk gnulib-modules-to-delete.cfg ../${tempdir}/nt + ln *.in ../${tempdir}/nt ln mingw-cfg.site epaths.nt INSTALL.W64 ../${tempdir}/nt ln ChangeLog.*[0-9] INSTALL README README.W32 ../${tempdir}/nt) diff --git a/nt/Makefile.in b/nt/Makefile.in index 89f4460..7e911db 100644 --- a/nt/Makefile.in +++ b/nt/Makefile.in @@ -54,11 +54,6 @@ am__v_CCLD_ = am__v_CCLD_0 = @echo " CCLD " $@; am__v_CCLD_1 = -AM_V_GEN = $(am__v_GEN_@AM_V@) -am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@) -am__v_GEN_0 = @echo " GEN " $@; -am__v_GEN_1 = - AM_V_RC = $(am__v_RC_@AM_V@) am__v_RC_ = $(am__v_RC_@AM_DEFAULT_V@) am__v_RC_0 = @echo " RC " $@; @@ -260,8 +255,3 @@ runemacs${EXEEXT}: emacs.res ../src/emacs.res: emacs.rc ${srcdir}/icons/emacs.ico \ ${srcdir}/icons/hand.cur ${srcdir}/$(EMACS_MANIFEST) $(AM_V_RC)${WINDRES} -I ${srcdir} -O coff -o $@ $< - -${srcdir}/gnulib.mk: ${srcdir}/gnulib-modules-to-delete.cfg ${srcdir}/../lib/gnulib.mk - $(AM_V_GEN)sed '/^[^#]/s|^.*$$|/^## begin *gnulib module &/,/^## end *gnulib module &/c ## gnulib module & removed|' < $< | \ - sed -f- ${srcdir}/../lib/gnulib.mk > $@-t && \ - ${srcdir}/../build-aux/move-if-change $@-t $@ diff --git a/nt/gnulib-modules-to-delete.cfg b/nt/gnulib-modules-to-delete.cfg deleted file mode 100644 index 09bea0e..0000000 --- a/nt/gnulib-modules-to-delete.cfg +++ /dev/null @@ -1,66 +0,0 @@ -# This is the list of modules to be deleted from ../lib/gnulib.mk. -# -# We delete them because they either conflict with MinGW headers or -# headers in nt/inc, or because those modules won't compile with -# MinGW, or because Emacs already has the corresponding facilities as -# part of Emacs sources, and their implementation is incompatible with -# Gnulib's. -# -# In general, do NOT remove anything from ../lib/gnulib.mk that -# doesn't need to be removed, to minimize the differences from -# upstream gnulib.mk and thus make the maintenance easier. Every -# header file whose generation is controlled by configure-time tests -# does NOT need to be removed; instead, force the configure script to -# accept whatever MinGW has to offer, by defining the appropriate -# Autoconf variable in the nt/mingw-cfg.site file. Headers that are -# generated conditionally have the tell-tale "if GL_GENERATE_foo_H" -# condition before their Makefile snippet in this file. Likewise, do -# NOT remove gnulib modules which introduce header files that don't -# exist in MinGW and in nt/inc/, since they cannot possibly clash -# with anything. Gnulib modules that introduce source *.c files also -# need not be removed; if they define functions that could clash with -# the w32 substitutes in Emacs, disable their compilation by defining -# suitable variables in nt/mingw-cfg.site. -# ---------------------------------------------------------------------- -# -# Copyright (C) 2017 Free Software Foundation, Inc. -# -# This file is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation; either version 3 of the License, or -# (at your option) any later version. -# -# This file is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this file. If not, see <http://www.gnu.org/licenses/>. -# -# As a special exception to the GNU General Public License, -# this file may be distributed as part of a program that -# contains a configuration script generated by Autoconf, under -# the same distribution terms as the rest of that program. -# -acl-permissions -allocator -at-internal -careadlinkat -dirent -dirfd -fcntl -fcntl-h -inttypes-incomplete -mkostemp -pipe2 -secure_getenv -signal-h -stdio -stdlib -sys_select -sys_stat -sys_time -sys_types -tempname -unistd -- 2.7.4 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 3:21 ` Paul Eggert @ 2017-01-05 9:30 ` Richard Copley 2017-01-05 9:54 ` Angelo Graziosi 2017-01-05 16:24 ` Eli Zaretskii 1 sibling, 1 reply; 21+ messages in thread From: Richard Copley @ 2017-01-05 9:30 UTC (permalink / raw) To: Paul Eggert; +Cc: Emacs developers, Angelo Graziosi On 5 January 2017 at 03:21, Paul Eggert <eggert@cs.ucla.edu> wrote: > Angelo Graziosi wrote: > >> Interfering nt/gnulib.mk from lib/gnulib.mk ... > > > Did it really say "Interfering"? :-) > >> sed: 46: "This is of m...": command c expects \ followed by text >> >> and the 'configure' is not created... > > > This is caused by our recent attempt to better-automate MS-Windows builds. I > fixed one nonportable construct, but evidently there are others. > > It's time to break out a bigger hammer. Please try the attached patch. I > have tested it on Fedora, but not on MS-Windows and so have not installed it > yet. Hi Paul, In MSYS2 on Windows, with the patch I get this error: gcc -DHAVE_CONFIG_H -I. -I../../repo/emacs/lib -I../src -I../../repo/emacs/src -march=native -mtune=native -D_WIN32_WINNT=_WIN32_WINNT_WIN7 -DUSE_CRT_DLL=1 -I /g/emacs/build/../repo/emacs/nt/inc -fno-common /* -W... */ -Og -g -ggdb -MT set-permissions.o -MD -MP -MF .deps/set-permissions.Tpo -c -o set-permissions.o ../../repo/emacs/lib/set-permissions.c ../../repo/emacs/lib/set-permissions.c: In function 'set_acls': ../../repo/emacs/lib/set-permissions.c:500:6: error: #error Must have acl_delete_def_file (see POSIX 1003.1e draft 17). # error Must have acl_delete_def_file (see POSIX 1003.1e draft 17). ^~~~~ ../../repo/emacs/lib/set-permissions.c:539:13: warning: implicit declaration of function 'acl_delete_def_file' [-Wimplicit-function-declaration] ret = acl_delete_def_file (name); ^~~~~~~~~~~~~~~~~~~ ../../repo/emacs/lib/set-permissions.c:539:7: warning: nested extern declaration of 'acl_delete_def_file' [-Wnested-externs] ret = acl_delete_def_file (name); ^~~ Without the patch, set-permissions.c isn't compiled. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 9:30 ` Richard Copley @ 2017-01-05 9:54 ` Angelo Graziosi 2017-01-05 15:42 ` Eli Zaretskii 2017-01-05 16:16 ` Eli Zaretskii 0 siblings, 2 replies; 21+ messages in thread From: Angelo Graziosi @ 2017-01-05 9:54 UTC (permalink / raw) To: Richard Copley, Paul Eggert; +Cc: Emacs developers Hi Paul, really I spoke of macOS build not MSWINDOWS (MSW).. But now, as Richard reported, it seems that also MSW build is broken... In any case > On 5 January 2017 at 03:21, Paul Eggert >> Did it really say "Interfering"? :-) Yes, I copy/pasted it.. You should consider that macOS does not use GNU sed but another version (unix/BSD?), and what works on GNU/Linux not always works in the same manne on macOS... Angelo ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 9:54 ` Angelo Graziosi @ 2017-01-05 15:42 ` Eli Zaretskii 2017-01-05 16:16 ` Eli Zaretskii 1 sibling, 0 replies; 21+ messages in thread From: Eli Zaretskii @ 2017-01-05 15:42 UTC (permalink / raw) To: Angelo Graziosi; +Cc: rcopley, eggert, emacs-devel > From: Angelo Graziosi <angelo.graziosi@alice.it> > Date: Thu, 5 Jan 2017 10:54:16 +0100 > Cc: Emacs developers <emacs-devel@gnu.org> > > Hi Paul, > > really I spoke of macOS build not MSWINDOWS (MSW).. But now, as Richard > reported, it seems that also MSW build is broken... No, it's not broken because Paul didn't install his changes. Richard was just giving him a heads-up. (Thanks, Richard!) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 9:54 ` Angelo Graziosi 2017-01-05 15:42 ` Eli Zaretskii @ 2017-01-05 16:16 ` Eli Zaretskii 2017-01-05 16:37 ` Angelo Graziosi 1 sibling, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2017-01-05 16:16 UTC (permalink / raw) To: Angelo Graziosi; +Cc: rcopley, eggert, emacs-devel > From: Angelo Graziosi <angelo.graziosi@alice.it> > Date: Thu, 5 Jan 2017 10:54:16 +0100 > Cc: Emacs developers <emacs-devel@gnu.org> > > You should consider that macOS does not use GNU sed but another version > (unix/BSD?), and what works on GNU/Linux not always works in the same > manne on macOS... That's my fault, not Paul's. Sorry about that. Could you please try the current master? I attempted to fix this problem. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 16:16 ` Eli Zaretskii @ 2017-01-05 16:37 ` Angelo Graziosi 2017-01-05 17:04 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Angelo Graziosi @ 2017-01-05 16:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rcopley, eggert, emacs-devel Il 05/01/2017 17:16, Eli Zaretskii ha scritto: >> From: Angelo Graziosi <angelo.graziosi@alice.it> >> Date: Thu, 5 Jan 2017 10:54:16 +0100 >> Cc: Emacs developers <emacs-devel@gnu.org> >> >> You should consider that macOS does not use GNU sed but another version >> (unix/BSD?), and what works on GNU/Linux not always works in the same >> manne on macOS... > > That's my fault, not Paul's. Sorry about that. > > Could you please try the current master? I attempted to fix this > problem. > On macOS same issue with master-003954e67fbe97c6ac786983912f572c48a331f5. Maybe this can help: http://lists.gnu.org/archive/html/emacs-devel/2017-01/msg00071.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 16:37 ` Angelo Graziosi @ 2017-01-05 17:04 ` Eli Zaretskii 2017-01-05 17:21 ` Angelo Graziosi 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2017-01-05 17:04 UTC (permalink / raw) To: Angelo Graziosi; +Cc: rcopley, eggert, emacs-devel > Cc: rcopley@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org > From: Angelo Graziosi <angelo.graziosi@alice.it> > Date: Thu, 5 Jan 2017 17:37:00 +0100 > > > Could you please try the current master? I attempted to fix this > > problem. > > > > On macOS same issue with master-003954e67fbe97c6ac786983912f572c48a331f5. Could you please show the error messages you see with the latest master? > Maybe this can help: > http://lists.gnu.org/archive/html/emacs-devel/2017-01/msg00071.html That didn't work on other systems, so we cannot use it as-is. Thanks. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 17:04 ` Eli Zaretskii @ 2017-01-05 17:21 ` Angelo Graziosi 2017-01-05 17:52 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Angelo Graziosi @ 2017-01-05 17:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rcopley, eggert, emacs-devel Il 05/01/2017 18:04, Eli Zaretskii ha scritto: >> Cc: rcopley@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org >> From: Angelo Graziosi <angelo.graziosi@alice.it> >> Date: Thu, 5 Jan 2017 17:37:00 +0100 >> >>> Could you please try the current master? I attempted to fix this >>> problem. >>> >> >> On macOS same issue with master-003954e67fbe97c6ac786983912f572c48a331f5. > > Could you please show the error messages you see with the latest > master? > Now it fails in similar way: ./autogen.sh [...] Your system has the required tools. Interfering nt/gnulib.mk from lib/gnulib.mk ... sed: 46: "# This is the list of m ...": extra characters after \ at the end of c command > >> Maybe this can help: >> http://lists.gnu.org/archive/html/emacs-devel/2017-01/msg00071.html > > That didn't work on other systems, so we cannot use it as-is. As I wrote, on macOS sed could behave differently.. it is not a GNU sed.. > > Thanks. > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 17:21 ` Angelo Graziosi @ 2017-01-05 17:52 ` Eli Zaretskii 2017-01-05 18:18 ` Andreas Schwab 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2017-01-05 17:52 UTC (permalink / raw) To: Angelo Graziosi; +Cc: rcopley, eggert, emacs-devel > Cc: rcopley@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org > From: Angelo Graziosi <angelo.graziosi@alice.it> > Date: Thu, 5 Jan 2017 18:21:50 +0100 > > > Could you please show the error messages you see with the latest > > master? > > > > Now it fails in similar way: > > ./autogen.sh > [...] > Your system has the required tools. > Interfering nt/gnulib.mk from lib/gnulib.mk ... > sed: 46: "# This is the list of m ...": extra characters after \ at the > end of c command How about now? > >> Maybe this can help: > >> http://lists.gnu.org/archive/html/emacs-devel/2017-01/msg00071.html > > > > That didn't work on other systems, so we cannot use it as-is. > > As I wrote, on macOS sed could behave differently.. it is not a GNU sed.. Yes, and as I wrote, I'm trying to find a solution that will work on all systems. Thanks. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 17:52 ` Eli Zaretskii @ 2017-01-05 18:18 ` Andreas Schwab 2017-01-05 18:24 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Andreas Schwab @ 2017-01-05 18:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rcopley, eggert, emacs-devel, Angelo Graziosi On Jan 05 2017, Eli Zaretskii <eliz@gnu.org> wrote: > How about now? echo is not portable wrt backslashes. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 18:18 ` Andreas Schwab @ 2017-01-05 18:24 ` Eli Zaretskii 2017-01-05 18:32 ` Andreas Schwab 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2017-01-05 18:24 UTC (permalink / raw) To: Andreas Schwab; +Cc: rcopley, eggert, emacs-devel, angelo.graziosi > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: Angelo Graziosi <angelo.graziosi@alice.it>, rcopley@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Thu, 05 Jan 2017 19:18:22 +0100 > > On Jan 05 2017, Eli Zaretskii <eliz@gnu.org> wrote: > > > How about now? > > echo is not portable wrt backslashes. Suggestions for how to fix this are welcome. I have no access to a macOS system, so I'm flying blind. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 18:24 ` Eli Zaretskii @ 2017-01-05 18:32 ` Andreas Schwab 2017-01-05 18:38 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Andreas Schwab @ 2017-01-05 18:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rcopley, eggert, emacs-devel, angelo.graziosi On Jan 05 2017, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Andreas Schwab <schwab@linux-m68k.org> >> Cc: Angelo Graziosi <angelo.graziosi@alice.it>, rcopley@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org >> Date: Thu, 05 Jan 2017 19:18:22 +0100 >> >> On Jan 05 2017, Eli Zaretskii <eliz@gnu.org> wrote: >> >> > How about now? >> >> echo is not portable wrt backslashes. > > Suggestions for how to fix this are welcome. I have no access to a > macOS system, so I'm flying blind. That has nothing to do with macos. $ echo '\\' \\ $ shopt -s xpg_echo $ echo '\\' \ Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 18:32 ` Andreas Schwab @ 2017-01-05 18:38 ` Eli Zaretskii 2017-01-05 18:53 ` Andreas Schwab 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2017-01-05 18:38 UTC (permalink / raw) To: Andreas Schwab; +Cc: rcopley, eggert, emacs-devel, angelo.graziosi > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: angelo.graziosi@alice.it, rcopley@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Thu, 05 Jan 2017 19:32:05 +0100 > > $ echo '\\' > \\ > $ shopt -s xpg_echo > $ echo '\\' > \ So you are saying that autogen.sh should do shopt -u xpg_echo to countermand a possible user setting? Strangely, whether I set xpg_echo or not, the current autogen.sh produces the same nt/gnulib.mk, although the effect on 'echo' is as you indicate above. So why doesn't that option have effect here? What am I missing? Thanks. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 18:38 ` Eli Zaretskii @ 2017-01-05 18:53 ` Andreas Schwab 2017-01-05 19:38 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Andreas Schwab @ 2017-01-05 18:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rcopley, eggert, emacs-devel, angelo.graziosi On Jan 05 2017, Eli Zaretskii <eliz@gnu.org> wrote: > Strangely, whether I set xpg_echo or not, the current autogen.sh > produces the same nt/gnulib.mk, although the effect on 'echo' is as > you indicate above. So why doesn't that option have effect here? Because you are relying on unspecified behaviour of the sed script. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 18:53 ` Andreas Schwab @ 2017-01-05 19:38 ` Eli Zaretskii 2017-01-05 22:41 ` Angelo Graziosi 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2017-01-05 19:38 UTC (permalink / raw) To: Andreas Schwab; +Cc: rcopley, eggert, emacs-devel, angelo.graziosi > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: angelo.graziosi@alice.it, rcopley@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Thu, 05 Jan 2017 19:53:17 +0100 > > On Jan 05 2017, Eli Zaretskii <eliz@gnu.org> wrote: > > > Strangely, whether I set xpg_echo or not, the current autogen.sh > > produces the same nt/gnulib.mk, although the effect on 'echo' is as > > you indicate above. So why doesn't that option have effect here? > > Because you are relying on unspecified behaviour of the sed script. Thanks. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 19:38 ` Eli Zaretskii @ 2017-01-05 22:41 ` Angelo Graziosi 2017-01-06 7:45 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Angelo Graziosi @ 2017-01-05 22:41 UTC (permalink / raw) To: Eli Zaretskii, Andreas Schwab; +Cc: rcopley, eggert, emacs-devel Last commit ( d1d9b376306edb77632968cbbd7dfa456f00046c) builds on macOS, MSW and GNU/Linux.. Thanks, Angelo. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 22:41 ` Angelo Graziosi @ 2017-01-06 7:45 ` Eli Zaretskii 2017-01-06 23:33 ` Angelo Graziosi 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2017-01-06 7:45 UTC (permalink / raw) To: Angelo Graziosi; +Cc: rcopley, eggert, schwab, emacs-devel > Cc: rcopley@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org > From: Angelo Graziosi <angelo.graziosi@alice.it> > Date: Thu, 5 Jan 2017 23:41:56 +0100 > > Last commit ( d1d9b376306edb77632968cbbd7dfa456f00046c) builds on macOS, > MSW and GNU/Linux.. Great, thanks for testing. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-06 7:45 ` Eli Zaretskii @ 2017-01-06 23:33 ` Angelo Graziosi 2017-01-06 23:43 ` Paul Eggert 0 siblings, 1 reply; 21+ messages in thread From: Angelo Graziosi @ 2017-01-06 23:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rcopley, eggert, schwab, emacs-devel Il 06/01/2017 08:45, Eli Zaretskii ha scritto: >> Cc: rcopley@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org >> From: Angelo Graziosi <angelo.graziosi@alice.it> >> Date: Thu, 5 Jan 2017 23:41:56 +0100 >> >> Last commit ( d1d9b376306edb77632968cbbd7dfa456f00046c) builds on macOS, >> MSW and GNU/Linux.. > > Great, thanks for testing. > Yes but, maybe, someone can clarify the following... I see that now autogen.sh prints the message: Inferring nt/gnulib.mk from lib/gnulib.mk ... Now, if I understand, 'nt' should refer to the build on MSW: Why, then, the same message in the build on GNU/Linux and on macOS? TIA, Angelo. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-06 23:33 ` Angelo Graziosi @ 2017-01-06 23:43 ` Paul Eggert 0 siblings, 0 replies; 21+ messages in thread From: Paul Eggert @ 2017-01-06 23:43 UTC (permalink / raw) To: Angelo Graziosi, Eli Zaretskii; +Cc: rcopley, schwab, emacs-devel On 01/06/2017 03:33 PM, Angelo Graziosi wrote: > > Now, if I understand, 'nt' should refer to the build on MSW: Why, > then, the same message in the build on GNU/Linux and on macOS? Becuase nt/gnulib.mk is built by the developer with special tools like 'autoconf', not by the builder who merely starts with a tarball and runs 'configure; make' and should not need the special tools. The whole thing is a bit of a mess, and the mess is largely caused by Emacs using Automake, and Automake is needed only because of Gnulib (because Gnulib assumes Automake for portability to older systems lacking GNU Make). I'll look into fixing this so that Gnulib no longer assumes Automake, so that Emacs can stop relying on Automake. Since Emacs assumes GNU Make, it doesn't need Automake (except for the Gnulib code, which I think I can fix). ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Last commit breaks macOS build 2017-01-05 3:21 ` Paul Eggert 2017-01-05 9:30 ` Richard Copley @ 2017-01-05 16:24 ` Eli Zaretskii 1 sibling, 0 replies; 21+ messages in thread From: Eli Zaretskii @ 2017-01-05 16:24 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel, angelo.graziosi > From: Paul Eggert <eggert@cs.ucla.edu> > Date: Wed, 4 Jan 2017 19:21:11 -0800 > > This is caused by our recent attempt to better-automate MS-Windows builds. I > fixed one nonportable construct, but evidently there are others. Yes, sorry about that. Mea culpa. > It's time to break out a bigger hammer. Please try the attached patch. I have > tested it on Fedora, but not on MS-Windows and so have not installed it yet. I'd prefer to avoid the need for the people who maintain the MS-Windows build to understand the structure of lib/gnulib.mk in too many details, such as what files comprise each Gnulib package, and what is the meaning of the likes of EXTRA_libgnu_a_SOURCES. OTOH, I'd prefer not to bother people who merge from Gnulib with understanding what parts the MS-Windows build needs to avoid. Having a simple list of Gnulib packages to remove from lib/gnulib.mk, similar to nt/gnulib-modules-to-delete.cfg, is therefore preferable to a much more detailed list that you propose to maintain manually in lib/Makefile.am. It is also simpler, since the syntax of Makefile.am doesn't need to be familiar to whoever modifies the list of modules. Is it possible to use a similar plain list of modules while solving this with GNU Make features? If not, I think we should stick with the current solution. It's not a bad one, I think, once we clean up the portability issues. (I just tried to solve a couple of such issues.) Thanks. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2017-01-06 23:43 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-01-04 10:08 Last commit breaks macOS build Angelo Graziosi 2017-01-05 3:21 ` Paul Eggert 2017-01-05 9:30 ` Richard Copley 2017-01-05 9:54 ` Angelo Graziosi 2017-01-05 15:42 ` Eli Zaretskii 2017-01-05 16:16 ` Eli Zaretskii 2017-01-05 16:37 ` Angelo Graziosi 2017-01-05 17:04 ` Eli Zaretskii 2017-01-05 17:21 ` Angelo Graziosi 2017-01-05 17:52 ` Eli Zaretskii 2017-01-05 18:18 ` Andreas Schwab 2017-01-05 18:24 ` Eli Zaretskii 2017-01-05 18:32 ` Andreas Schwab 2017-01-05 18:38 ` Eli Zaretskii 2017-01-05 18:53 ` Andreas Schwab 2017-01-05 19:38 ` Eli Zaretskii 2017-01-05 22:41 ` Angelo Graziosi 2017-01-06 7:45 ` Eli Zaretskii 2017-01-06 23:33 ` Angelo Graziosi 2017-01-06 23:43 ` Paul Eggert 2017-01-05 16:24 ` Eli Zaretskii
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.