From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bruno Haible Newsgroups: gmane.emacs.bugs Subject: bug#8675: error: token "@" is not valid in preprocessor expressions Date: Thu, 19 May 2011 02:27:24 +0200 Message-ID: <201105190227.26215.bruno__43051.4934858822$1305765194$gmane$org@clisp.org> References: <4DD0B118.1040205@cs.ucla.edu> <4DD44F42.1050405@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1305765194 31997 80.91.229.12 (19 May 2011 00:33:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 19 May 2011 00:33:14 +0000 (UTC) Cc: Christoph Scholtes , Andreas Schwab , Paul Eggert , 8675@debbugs.gnu.org To: bug-gnulib@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 19 02:33:09 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QMr61-0006Qc-7D for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 May 2011 02:33:09 +0200 Original-Received: from localhost ([::1]:48168 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMr60-0001Qy-PB for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 May 2011 20:28:08 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMr5y-0001Qp-3X for bug-gnu-emacs@gnu.org; Wed, 18 May 2011 20:28:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMr5u-00039w-Sy for bug-gnu-emacs@gnu.org; Wed, 18 May 2011 20:28:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMr5u-00039s-PP for bug-gnu-emacs@gnu.org; Wed, 18 May 2011 20:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QMr5u-00008k-Ar; Wed, 18 May 2011 20:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Bruno Haible Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 May 2011 00:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8675 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8675-submit@debbugs.gnu.org id=B8675.1305764857508 (code B ref 8675); Thu, 19 May 2011 00:28:02 +0000 Original-Received: (at 8675) by debbugs.gnu.org; 19 May 2011 00:27:37 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMr5U-000088-R2 for submit@debbugs.gnu.org; Wed, 18 May 2011 20:27:37 -0400 Original-Received: from mo-p00-ob.rzone.de ([81.169.146.160]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMr5R-00007q-Uo for 8675@debbugs.gnu.org; Wed, 18 May 2011 20:27:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1305764847; l=2951; s=domk; d=haible.de; h=Content-Transfer-Encoding:Content-Type:MIME-Version:In-Reply-To: References:Cc:Date:Subject:To:From:X-RZG-CLASS-ID:X-RZG-AUTH; bh=9AGvdFsJGCmzA5ojjN4y1qdsLww=; b=GuWT2rRlJ8xwmPMkdxXQzBa9KR36cGmab5KBjFCb1PlyRgrXK08ksiR8sXUihJJKQnu h36O1oEMCscXO4Gz6QtDjSXYoOQOBS/KMWh7PvRbYs9ZKveZ92rqqdfX1phvlK9WfmTbz uxCCGctgwE3s5mEBeIzoaT5EMva13HsxJck= X-RZG-AUTH: :Ln4Re0+Ic/6oZXR1YgKryK8brksyK8dozXDwHXjf9hj/zDNRbvU45h26 X-RZG-CLASS-ID: mo00 Original-Received: from linuix.haible.de (dslb-088-068-073-041.pools.arcor-ip.net [88.68.73.41]) by post.strato.de (cohen mo1) (RZmta 25.18) with ESMTPA id e03564n4ILG2nD ; Thu, 19 May 2011 02:27:26 +0200 (MEST) User-Agent: KMail/1.9.9 In-Reply-To: <4DD44F42.1050405@cs.ucla.edu> Content-Disposition: inline X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 18 May 2011 20:28:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:46574 Archived-At: Hi Paul, > all we need to do is to have unistd.h > depend on Makefile. And, once unistd.h depends on Makefile > then it need not depend on config.status (as Makefile already > depends on config.status). Like this: > > --- a/modules/unistd > +++ b/modules/unistd > @@ -20,7 +20,7 @@ BUILT_SOURCES += unistd.h > > # We need the following in order to create an empty placeholder for > # when the system doesn't have one. > -unistd.h: unistd.in.h $(top_builddir)/config.status $(CXXDEFS_H) $(ARG_NONNULL_H) $(WARN_ON_USE_H) > +unistd.h: unistd.in.h Makefile $(CXXDEFS_H) $(ARG_NONNULL_H) $(WARN_ON_USE_H) > $(AM_V_GEN)rm -f $@-t $@ && \ > { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ > sed -e 's|@''HAVE_UNISTD_H''@|$(HAVE_UNISTD_H)|g' \ > Such a change would have the effect that hand-editing a Makefile would cause all gnulib *.h files to be regenerated and, with it, all *.o files would be recompiled. However, hand-editing a Makefile is necessary in two situations at least: 1) to test a certain modification of compilation commands, before putting the changes into Makefile.am, 2) to trace the effect of C compiler bugs, by compiling different *.o files with different compiler optimization levels. I'm therefore vehemently opposed to such a change. In fact, in the thread starting at we developed some Automake tests for guaranteeing that everything is properly rebuilt, and it turned out that 1. some specific code pattern is necessary in the module descriptions, and it was implemented on 2011-04-03, 2. GNU make is necessary as well. But that's it. So, if the reporter was using GNU make and the previous Makefile.in was based on gnulib 2011-04-03 or newer and the reporter did a make command in the top-level directory that recreated config.status before recursing into lib/ and then into src/, then the situation cannot have occurred. If the reporter was not using GNU make, he should do so. It has become clear through the tests in Automake that GNU make is a requirement for rebuilds to be reliable. If the previous Makefile.in was not based on gnulib 2011-04-03 or newer, we need to do nothing; the problem is already fixed. If the reporter did "make" in the top-level directory of emacs and it did not rebuild config.status, even after configure changed, it needs to be fixed in emacs. If the reporter only did "make" in the lib/ or src/ subdirectory and not in the top-level directory, then either he needs to change his way of working, or a rule like ../config.status : $(srcdir)/../configure ../config.status --recheck needs to be added in every subdirectory's Makefile. Automake generated Makefiles contain such a rule, so maybe that's what is missing in emacs/src/Makefile? Bruno -- In memoriam Eli Cohen