Bug 28403

Summary: Re: make(1) does not correctly substitute in internal macros like $(@F:.o=.c)
Product: Base System Reporter: Jens.Schweikhardt <Jens.Schweikhardt>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me CC: jens
Priority: Normal    
Version: 1.0-RELEASE   
Hardware: Any   
OS: Any   

Description Jens.Schweikhardt 2001-06-25 10:50:00 UTC
 On Sat, Jun 23, 2001 at 05:47:04PM +0000, Giorgos Keramidas wrote:
 # On Tue, Jan 16, 2001 at 02:44:12AM -0800, Jens.Schweikhardt@marconi.com wrote:
 # 
 # > >Description:
 # > 
 # > It seems, make(1) doesn't understand substitutions in what the POSIX
 # > standard calls internal variables ($@, $%, $?, $< and $*).
 # > In the following example, the intent is to substitute any *.o in a *.c,
 # > i.e. echo foo.c.
 # > 
 # > >How-To-Repeat:
 # > $ cat Makefile                  
 # > .POSIX:
 # > foo.o:
 # >         echo $(@F:.o=.c)
 # > $ /usr/bin/make
 # > echo foo.o.o=.c)
 # > Syntax error: ")" unexpected
 # > *** Error code 2
 # > 
 # > Stop in /usr/home/sje2bk.
 # 
 # Jens, are you sure this problem still persists to bug you?
  
 Yes.
 
 # Well, the syntax is slightly different in the make(1) program I have
 # on my 5.0-CURRENT, and by looking at the CVS logs, it seems that its
 # been like that for a while.  The way that BSD make does substitution
 # in variables, special or not is described in the paper found at
 # /usr/share/doc/psd/12.make/paper.* and an example of it is shown
 # below:
  
 That document also says:
 
   In addition, the System V style of substitution is also sup-
   ported.  This looks like:
 
         $(VARIABLE:search-string=replacement)
 
 and I can see nothing that says I couldn't use @F for VARIABLE here.
 
 ...
 # Am afraid that I don't know if POSIX specifies a different syntax than
 # the ${VARIABLE:modifier} that BSD make uses.
 
 I've got the old (1995) and soon-to-be (2001) POSIX specs near me.
 They are very clear. I know of the workaround; but I'm interested in
 having /usr/bin/make be POSIX compliant. There are makefiles out there
 that use this feature and they fail on BSD for no good reason.
 The latest and final POSIX draft says;
 
  Macro expansions using the forms $(string1[:subst1=[subst2]]) or
  ${string1[:subst1=[subst2]]} can be used to replace all occurrences of
  subst1 with subst2 when the macro substitution is performed. The subst1
  to be replaced shall be recognized when it is a suffix at the end of a
  word in string1 (where a word, in this context, is defined to be a
  string delimited by the beginning of the line, a <blank> or <newline>).
  If string1 in a macro expansion contains a macro expansion, the results
  are unspecified. Macro expansions in string1 of macro definition lines
  shall be evaluated when read. Macro expansions in string2 of macro
  definition lines shall be performed when the macro identified by
  string1 is expanded in a rule or command.
 
 #  On the other hand, the
 # version of GNU make that I have says in its manuals that substitution
 # in variables works a little differently than what you wrote.
  
 Not really; the % way of doing substitution is a GNU extension.
 It's not POSIX. It's just another (albeit more flexible) way of doing
 substitution. And as you can see in my original PR, GNU gets the POSIX
 substitution right.
 
 # 	% cat GNUmakefile 
 # 	
 # 	SRCS=   main.c foo.c
 # 	
 # 	OBJS=   $(SRCS:%.c=%.o)
 # 	
 # 	all:
 # 		echo $(OBJS)
 # 	
 # 	% gmake -f GNUmakefile 
 # 	
 # 	echo main.o foo.o
 # 	main.o foo.o
 # 
 # I think we can close this PR, if thats ok with you Jens too.
 
 Please leave it open. This is a real bug. POSIX substitution
 works in other circumstance with regular variables, just not with
 automatics using D (directory part) and F (filename part) modifiers:
 
 .POSIX:
 FOO = bar.o
 
 all:
     @echo '$(FOO:.o=.c)'
 bar.o:
     @echo '$(@F:.o=.c)'
 zap.o:
     @echo '$(@:.o=.c)'
 
 
 $ make all
 bar.c                  # works
 $ make bar.o
 bar.o.o=.c)            # buggy, should be bar.c
 $ make zap.o
 zap.c                  # works
 
 Regards,
 
 	Jens
 -- 
 Jens Schweikhardt  http://www.schweikhardt.net/
 SIGSIG -- signature too long (core dumped)
Comment 1 greid freebsd_committer freebsd_triage 2001-07-02 19:32:42 UTC
Responsible Changed
From-To: gnats-admin->will

Misfiled; should be part of the audit trail of 24377 which will is responsible for.
Comment 2 Will Andrews freebsd_committer freebsd_triage 2001-08-30 00:25:17 UTC
Responsible Changed
From-To: will->freebsd-bugs

I don't have time for make(1) anymore...
Comment 3 Giorgos Keramidas freebsd_committer freebsd_triage 2001-10-17 01:29:43 UTC
State Changed
From-To: open->closed

This is a duplicate of 24377.