From jhs@jhs.muc.de  Fri Mar  9 01:28:51 2001
Return-Path: <jhs@jhs.muc.de>
Received: from jhs.muc.de (jhs.muc.de [193.149.49.84])
	by hub.freebsd.org (Postfix) with ESMTP id 4317837B71A
	for <FreeBSD-gnats-submit@freebsd.org>; Fri,  9 Mar 2001 01:28:48 -0800 (PST)
	(envelope-from jhs@jhs.muc.de)
Received: (from jhs@localhost)
	by jhs.muc.de (8.11.0/8.11.0) id f28G4s419991;
	Thu, 8 Mar 2001 16:04:54 GMT
	(envelope-from jhs)
Message-Id: <200103081604.f28G4s419991@jhs.muc.de>
Date: Thu, 8 Mar 2001 16:04:54 GMT
From: jhs@freebsd.org
Reply-To: jhs@jhs.muc.de
To: FreeBSD-gnats-submit@freebsd.org
Subject: Cannot append hash after .elif in Makefile, (but can after .if)
X-Send-Pr-Version: 3.2

>Number:         25627
>Category:       bin
>Synopsis:       Cannot append hash after .elif in Makefile, (but can after .if)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    harti
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 09 01:30:01 PST 2001
>Closed-Date:    Thu Jul 22 11:15:24 GMT 2004
>Last-Modified:  Thu Jul 22 11:15:24 GMT 2004
>Originator:     Julian Stacey jhs@jhs.muc.de
>Release:        FreeBSD 4.2-RELEASE i386
>Organization:
FreeBSD
>Environment:

`man make` says:
  Comments begin with a hash (`#') character, anywhere but in a shell com-
  mand line, and continue to the end of the line.

To understand a complex Makefile like /usr/src/release/Makefile
with nested .if .endif conditionals, it is useful to hang "#{" & "#}"
at end of lines & use the "%" key in vi to bounce between matching braces.
This fails on .elif

>Description:

The expansion of .elif uses everything up to '\n' & allows no
'#' comment delimeter as available to simpler .if & .else & .endif commands.

>How-To-Repeat:

mkdir ~/tmp ; cd ~/tmp ; cat > Makefile << EOF
break:
.if defined(AA)		#{AA
	@echo 11
.elif defined(BB)	#}{!AA{BB
	@echo 22
.else			#}{!BB
	@echo 33
.endif			#}}

ok:
.if defined(AA)		#{AA
	@echo 11
.else			#}{!AA
.if defined(BB)		#{BB
	@echo 22
.else			#}{!BB
	@echo 33
.endif			#}
.endif			#}
EOF
make

"Makefile", line 4: Malformed conditional (defined(BB)  #}{!AA{BB)
make: fatal errors encountered -- cannot continue

>Fix:
Document it - until a make guru fixes it sometime, maybe.
*** 4.2-RELEASE/src/usr.bin/make/make.1	Thu Oct 19 06:23:49 2000
--- new/src/usr.bin/make/make.1	Thu Mar  8 16:53:43 2001
***************
*** 1238,1243 ****
--- 1238,1273 ----
  \&.endfor
  .Ed
  won't work, and should be rewritten the other way around.
+ .Pp
+ The expansion of .elif uses everything up to end of line, & allows no
+ # comment delimeter as available to simpler .if & .else & .endif commands.
+ .br
+ This thus fails;
+ .in +2
+ .nf
+  .if defined(AA)         #{AA
+          @echo 11
+  .elif defined(BB)       #}{!AA{BB
+          @echo 22
+  .else                   #}{!BB
+          @echo 33
+  .endif                  #}}
+ .fi
+ .in -2
+ Whereas this works
+ .in +2
+ .nf
+  .if defined(AA)         #{AA
+          @echo 11
+  .else                   #}{!AA
+  .if defined(BB)         #{BB
+          @echo 22
+  .else                   #}{!BB
+          @echo 33
+  .endif                  #}
+  .endif                  #}
+ .fi
+ .in -2
  .Sh SEE ALSO
  .Xr mkdep 1
  .Rs
>Release-Note:
>Audit-Trail:

From: Seth Kingsley <sethk@osd.bsdi.com>
To: freebsd-gnats-submit@FreeBSD.org, jhs@jhs.muc.de
Cc:  
Subject: Re: bin/25627: Cannot append hash after .elif in Makefile, (but can after .if)
Date: Wed, 14 Mar 2001 16:56:58 -0800

 Make's parser skips down to the next conditional (line beginning with a
 '.') when the current conditional evaluates to false. The function
 parse.c:ParseSkipLine() does not handle comments in the same way that
 parse.c:ParseReadLine() does, and thus causes errors such as this one.
 This patch adds the correct behavior to parse.c:ParseSkipLine.
 
 Index: parse.c
 ===================================================================
 RCS file: /ncvs/src/usr.bin/make/parse.c,v
 retrieving revision 1.22
 diff -u -r1.22 parse.c
 --- parse.c	1999/08/28 01:03:35	1.22
 +++ parse.c	2001/03/14 21:02:37
 @@ -2059,18 +2059,24 @@
  
          while (((c = ParseReadc()) != '\n' || lastc == '\\')
                 && c != EOF) {
 -            if (c == '\n') {
 -                Buf_ReplaceLastByte(buf, (Byte)' ');
 -                lineno++;
 +            if (c == '#' && lastc != '\\') {
 +                while ((c = ParseReadc()) != '\n' && c != EOF);
  
 -                while ((c = ParseReadc()) == ' ' || c == '\t');
 +                break;
 +            } else {
 +                if (c == '\n') {
 +                    Buf_ReplaceLastByte(buf, (Byte)' ');
 +                    lineno++;
  
 -                if (c == EOF)
 -                    break;
 -            }
 +                    while ((c = ParseReadc()) == ' ' || c == '\t');
 +
 +                    if (c == EOF)
 +                        break;
 +                }
  
 -            Buf_AddByte(buf, (Byte)c);
 -            lastc = c;
 +                Buf_AddByte(buf, (Byte)c);
 +                lastc = c;
 +            }
          }
  
          if (c == EOF) {
 
 -- 
 || Seth Kingsley || BSDi/Open Source Division || sethk@osd.bsdi.com ||
Responsible-Changed-From-To: freebsd-bugs->will 
Responsible-Changed-By: will 
Responsible-Changed-When: Wed Mar 14 18:02:22 PST 2001 
Responsible-Changed-Why:  
Remind myself to get this fixed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25627 
State-Changed-From-To: open->suspended 
State-Changed-By: will 
State-Changed-When: Wed Mar 14 18:51:22 PST 2001 
State-Changed-Why:  
Reminder to MFC this after sufficient testing in -CURRENT. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25627 
Responsible-Changed-From-To: will->freebsd-bugs 
Responsible-Changed-By: will 
Responsible-Changed-When: Wed Aug 29 16:26:47 PDT 2001 
Responsible-Changed-Why:  
I don't have time for make(1) anymore... 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25627 

From: Sheldon Hearn <sheldonh@starjuice.net>
To: bug-followup@freebsd.org
Cc: jkh@FreeBSD.org, jhay@FreeBSD.org
Subject: Re: bin/25627: Cannot append hash after .elif in Makefile
Date: Thu, 24 Jan 2002 14:17:18 +0200

 For the audit trail:
 
 This one is _not_ awaiting MFC.  The patch was backed out in the following
 commit to parse.c:
 
 --------
 revision 1.28
 date: 2001/03/15 10:22:50;  author: will;  state: Exp;  lines: +10 -16
 Revert previous change -- apparently it's not quite right.  It broke
 src/sys/modules/if_ef and possibly other things.  I tested the build
 with
 a make based on rev. 1.26, and it worked fine.  Since I'm not
 particularly
 inclined to figure out what's going on with this, it's probably prudent
 just to back it out for now.
 
 Found by:	jkh
 Suggested by:	jhay
 --------
 
 Jordan, John?  Does either one of you have any more information that's
 likely to get this PR out of suspended state?  The audit trail doesn't
 include any objections to the patch.
 
 Ciao,
 Sheldon.

From: John Hay <jhay@icomtek.csir.co.za>
To: sheldonh@starjuice.net (Sheldon Hearn)
Cc: freebsd-bugs@FreeBSD.ORG
Subject: Re: bin/25627: Cannot append hash after .elif in Makefile
Date: Wed, 30 Jan 2002 11:32:42 +0200 (SAT)

 >  For the audit trail:
 >  
 >  This one is _not_ awaiting MFC.  The patch was backed out in the following
 >  commit to parse.c:
 >  
 >  --------
 >  revision 1.28
 >  date: 2001/03/15 10:22:50;  author: will;  state: Exp;  lines: +10 -16
 >  Revert previous change -- apparently it's not quite right.  It broke
 >  src/sys/modules/if_ef and possibly other things.  I tested the build
 >  with
 >  a make based on rev. 1.26, and it worked fine.  Since I'm not
 >  particularly
 >  inclined to figure out what's going on with this, it's probably prudent
 >  just to back it out for now.
 >  
 >  Found by:	jkh
 >  Suggested by:	jhay
 >  --------
 >  
 >  Jordan, John?  Does either one of you have any more information that's
 >  likely to get this PR out of suspended state?  The audit trail doesn't
 >  include any objections to the patch.
 
 The only reason my name got dragged into this pr is because I complained
 that the patch caused make world/release to fail. As such I don't have
 anything against what the patch try to achieve as long as it does not
 break things.
 
 John
 -- 
 John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org

From: Sheldon Hearn <sheldonh@starjuice.net>
To: John Hay <jhay@icomtek.csir.co.za>
Cc: bug-followup@freebsd.org
Subject: Re: bin/25627: Cannot append hash after .elif in Makefile 
Date: Wed, 30 Jan 2002 11:56:17 +0200

 On Sat, 30 Jan 2002 11:32:42 +0200, John Hay wrote:
 
 > The only reason my name got dragged into this pr is because I complained
 > that the patch caused make world/release to fail. As such I don't have
 > anything against what the patch try to achieve as long as it does not
 > break things.
 
 Okay, so if I can come up with a patch that doesn't break world, you're
 okay with it?  Would you be prepared to test patches through the release
 target?
 
 Ciao,
 Sheldon.

From: John Hay <jhay@icomtek.csir.co.za>
To: sheldonh@starjuice.net (Sheldon Hearn)
Cc: bug-followup@freebsd.org
Subject: Re: bin/25627: Cannot append hash after .elif in Makefile
Date: Wed, 30 Jan 2002 11:57:50 +0200 (SAT)

 > 
 > > The only reason my name got dragged into this pr is because I complained
 > > that the patch caused make world/release to fail. As such I don't have
 > > anything against what the patch try to achieve as long as it does not
 > > break things.
 > 
 > Okay, so if I can come up with a patch that doesn't break world, you're
 > okay with it?  Would you be prepared to test patches through the release
 > target?
 
 Yes I'll push them through a "make release" for you.
 
 John
 -- 
 John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org

From: Sheldon Hearn <sheldonh@starjuice.net>
To: Seth Kingsley <sethk@osd.bsdi.com>
Cc: bug-followup@freebsd.org
Subject: Re: bin/25627: Cannot append hash after .elif in Makefile
Date: Tue, 05 Feb 2002 11:57:19 +0200

 Hi Seth,
 
 The patch you submitted against make(1) to fix the problem reported in
 FreeBSD PR bin/25627 was reported to break the 'release' target.
 
 Did you do any further work in this area?
 
 Ciao,
 Sheldon.
State-Changed-From-To: suspended->open 
State-Changed-By: harti 
State-Changed-When: Wed Jul 21 17:51:06 GMT 2004 
State-Changed-Why:  
I think I have a working patch. The problem with the original patch 
seems to be that the function in question (ParseSkipLine) is called from 
two places to do two entirely different things: with skip=true it is called 
from the conditional handling code to skip false .if contents until a 
line beginning with a dot is found. All input is discarded in this case. 
It is also called from the .for handling code to collect the for loop. 
In this case skip=false and the function will return the entire for loop. 

In the latter case we should not skip comments, because this must be done 
in the main code. Comment skipping is just a little bit more complex 
than just looking for a '#'. Think of: 

foo: 
echo '#define INET' >opt_inet.h 

harti 



Responsible-Changed-From-To: freebsd-bugs->harti 
Responsible-Changed-By: harti 
Responsible-Changed-When: Wed Jul 21 17:51:06 GMT 2004 
Responsible-Changed-Why:  
I think I have a working patch. The problem with the original patch 
seems to be that the function in question (ParseSkipLine) is called from 
two places to do two entirely different things: with skip=true it is called 
from the conditional handling code to skip false .if contents until a 
line beginning with a dot is found. All input is discarded in this case. 
It is also called from the .for handling code to collect the for loop. 
In this case skip=false and the function will return the entire for loop. 

In the latter case we should not skip comments, because this must be done 
in the main code. Comment skipping is just a little bit more complex 
than just looking for a '#'. Think of: 

foo: 
echo '#define INET' >opt_inet.h 

harti 


http://www.freebsd.org/cgi/query-pr.cgi?pr=25627 
State-Changed-From-To: open->closed 
State-Changed-By: harti 
State-Changed-When: Thu Jul 22 11:14:57 GMT 2004 
State-Changed-Why:  
New patch committed. Thanks. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25627 
>Unformatted:
