From psmith@baynetworks.com Wed Jul 11 02:08:41 2001 Received: from ns1.baynetworks.com ([134.177.3.20] helo=baynet.baynetworks.com) by fencepost.gnu.org with esmtp (Exim 3.22 #1 (Debian)) id 15KDAv-0001XM-00; Wed, 11 Jul 2001 02:08:41 -0400 Received: from mailhost.BayNetworks.COM (ns1.baynetworks.com [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id XAA23745; Tue, 10 Jul 2001 23:06:35 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id XAA07074; Tue, 10 Jul 2001 23:06:30 -0700 (PDT) Received: from lemming.engeast.baynetworks.com (lemming [192.32.150.127]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id CAA09176; Wed, 11 Jul 2001 02:08:37 -0400 for Received: from psmith by lemming.engeast.baynetworks.com with local (Exim 3.22 #1 (Debian)) id 15KDAj-000110-00; Wed, 11 Jul 2001 02:08:29 -0400 From: "Paul D. Smith" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15179.60757.654997.316732@lemming.engeast.baynetworks.com> Date: Wed, 11 Jul 2001 02:08:21 -0400 To: make-alpha@gnu.org, automake@gnu.org Subject: Semantic strangeness in parsing makefiles X-Mailer: VM 6.92 under Emacs 20.7.2 Sender: make-alpha-admin@gnu.org Errors-To: make-alpha-admin@gnu.org X-BeenThere: make-alpha@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for GNU make alpha testers and developers List-Unsubscribe: , List-Archive: I'm almost done with the multi-line expansion feature which is the main new feature to be introduced in GNU make 3.80. While doing this I modified, somewhate sanitized, and extensively documented :), the portion of the reading of makefiles that handles target definitions. In so doing, however, I have modified the behavior of make. I'm looking into putting it back the way it was, but it's kind of gross. Also, I think that the old behavior was not very well defined itself. There is no mention of this in the GNU make manual that I can see, but there is one regression test that fails due to the change. Anyway, here it is: The current algorithm for expanding rule definition lines in GNU make is this: take each word on the line and var-expand it. Then, walk the expansion of that word looking for ":" or "::" tokens. If we find one, that's the first colon for the rule definition. If there's no colon there, go to the next word on the line and expand and search that. If we get to the end of the line and no colon appears, then it's a missing separator error (at this point we already know it's not a variable assignment or preprocessor statement). The new algorithm is this: look through the _unexpanded_ line, for a ":" or "::" token. If we find one, then expand everything to the left of that and chop it up on whitespace separators into targets. If no colon is found, then this line is expanded and pushed back onto the makefile read stream, and we start over with a new line. In practice, the only place I can find where the differences between these two algorithms changes the result is in a situation where one of the variables in the target list expands to contain a colon: FOO = bar:baz $(FOO) biz : boz Current versions of GNU make will parse this as: bar : baz biz : boz where the target is just "bar". This is actually a syntax error, since GNU make expects this to be a static pattern rule, but there are no pattern chars. The new version of GNU make will parse the above as: bar:baz biz : boz where there are two targets: "bar:baz" and "biz", and one prerequisite, "boz". So, what do people think about this? Is it simpler to understand the new way, or the old way? Do you think the old behavior is documented (I couldn't find it) or standardized enough that there are live makefiles that use it? In normal make you'd always get a syntax error AFAICT, since you have two separate colons on the line. In GNU make this _could_ be a legal construct, but it would have to expand to a legal static pattern rule. I'm willing to fix it to behave as before, if that seems the best, but there will be some (small) performance penalty involved. It's just not clear to me that this older behavior is really specified anywhere, or even desirable, really. Comments? -- ------------------------------------------------------------------------------- Paul D. Smith HASMAT--HA Software Methods & Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ------------------------------------------------------------------------------- These are my opinions---Nortel Networks takes no responsibility for them. From tim.van.holder@pandora.be Wed Jul 11 03:46:05 2001 Received: from hercules.telenet-ops.be ([195.130.132.33] helo=smtp1.pandora.be) by fencepost.gnu.org with smtp (Exim 3.22 #1 (Debian)) id 15KEhA-0005sN-00 for ; Wed, 11 Jul 2001 03:46:05 -0400 Received: (qmail 25322 invoked from network); 11 Jul 2001 07:46:03 -0000 Received: from unknown (HELO zastaicentral) ([213.224.248.185]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 11 Jul 2001 07:46:03 -0000 From: "Tim Van Holder" To: "Paul D. Smith" , , Subject: Re: Semantic strangeness in parsing makefiles Date: Wed, 11 Jul 2001 09:46:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15179.60757.654997.316732@lemming.engeast.baynetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: make-alpha-admin@gnu.org Errors-To: make-alpha-admin@gnu.org X-BeenThere: make-alpha@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for GNU make alpha testers and developers List-Unsubscribe: , List-Archive: > FOO = bar:baz > > $(FOO) biz : boz > > Current versions of GNU make will parse this as: > > bar : baz biz : boz That IS gross - I don't think we want that. > So, what do people think about this? Is it simpler to understand the > new way, or the old way? Do you think the old behavior is documented (I I think the new way is better, provided indeed that there are few (if any) existing Makefiles that depend on this behaviour. From oliva@lsd.ic.unicamp.br Wed Jul 11 07:42:20 2001 Received: from guarana.lsd.ic.unicamp.br ([143.106.24.130]) by fencepost.gnu.org with esmtp (Exim 3.22 #1 (Debian)) id 15KINn-0003Ht-00; Wed, 11 Jul 2001 07:42:19 -0400 Received: (from aoliva@localhost) by guarana.lsd.ic.unicamp.br (8.11.2/8.11.2) id f6BBgE415930; Wed, 11 Jul 2001 08:42:14 -0300 To: "Paul D. Smith" Cc: make-alpha@gnu.org, automake@gnu.org Subject: Re: Semantic strangeness in parsing makefiles References: <15179.60757.654997.316732@lemming.engeast.baynetworks.com> From: Alexandre Oliva Date: 11 Jul 2001 08:42:14 -0300 In-Reply-To: <15179.60757.654997.316732@lemming.engeast.baynetworks.com> ("Paul D. Smith"'s message of "Wed, 11 Jul 2001 02:08:21 -0400") Message-ID: Lines: 23 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: make-alpha-admin@gnu.org Errors-To: make-alpha-admin@gnu.org X-BeenThere: make-alpha@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for GNU make alpha testers and developers List-Unsubscribe: , List-Archive: On Jul 11, 2001, "Paul D. Smith" wrote: > FOO = bar:baz > $(FOO) biz : boz > The new version of GNU make will parse the above as: > bar:baz biz : boz > where there are two targets: "bar:baz" and "biz", and one prerequisite, > "boz". This is excellent. It means there's finally a way to have a target whose name contains a colon. Please don't go back to the original behavior. I don't believe anybody can possibly expect that feature to be reliable. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist *Please* write to mailing lists, not to me