bugmake - Bugs: bug #36800, False misidentification of '%' as...

 
 

bug #36800: False misidentification of '%' as "mixed" target in a single target specififcation

Submitted by:  Serguei Mokhov <mokhov>
Submitted on:  Fri 06 Jul 2012 03:16:22 PM UTC  
 
Severity:  3 - Normal Item Group:  Bug
Status:  Not A Bug Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  3.82 Operating System:  Any
Fixed Release:  None Triage Status:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 06 Jul 2012 05:57:30 PM UTC, comment #3: 

Previously make didn't throw an error on the syntax.  But the rule always had the problem that the file you created was not the same as the one you told make you'd create.

Most likely you never noticed this because with a prerequisite like "all" (which is probably .PHONY) the rule always rebuilt anyway.  But if you had your makefile set up so that it would only rebuild the tarball if some part of the build actually changed, then you would see that in fact make would recreate this tarball always, even if nothing else changed.

Cheers!

Paul D. Smith <psmith>
Project Administrator
Fri 06 Jul 2012 05:52:36 PM UTC, comment #2: 

Hi Paul,

Thanks for the comment and the workaround with $(shell ...). I knew the back ticks were interpreted at the rule time by the shell and not at the make variable assignment time, but it only became a problem when I started using make 3.82; all the makefiles worked properly in the previous years with the syntax I gave so I never changed it. I of course was confused at first when I hit this on an seemingly unrelated issue. You are correct about the overnight builds and other issues; and I will update the makefile code per your suggestion.

Thanks a lot!

-s

Serguei Mokhov <mokhov>
Fri 06 Jul 2012 05:14:41 PM UTC, comment #1: 

Hi Serguei; this is a problem with your makefile, and has nothing to do with GNU make.

The problem is that you think make is going to expand backquotes.  Backquotes are a shell feature, and make doesn't do anything special with backquotes.

As a result, the target your makefile has told make will be built by this rule is actually the literal string "myapp-bundle-0.3.1-devel-`date +%Y%m%d`.tar.gz"

Now, when that value appears in the command script of the rule, the shell sees it and expands it properly, but make does not.

If you want to have the results of a shell command used in a make variable then there is only one way to do it: with the $(shell ...) function.  Something like this:

    ...
DATESTAMP := $(shell date +%Y%m%d)
VERSION    = 0.3.1-devel-$(DATESTAMP)
DATAEXE    = myapp
    ...
$(DATAEXE)-bundle-$(VERSION).tar.gz: all #...
    ...

This is better anyway, because if you do a build just around midnight, then it's possible different invocations of the date command could return different values.  Better to ensure that all rules and targets use the same value, computed only one time.

Paul D. Smith <psmith>
Project Administrator
Fri 06 Jul 2012 03:16:22 PM UTC, original submission:  

First, I am aware of the bug #33034 and the new (3.82) make's /feature/ of disallowing mixed targets. I am hitting a related bug to the same but with erronous parsing. My observation is that the feature introduced a "presumed guilty" parsing bug and I am getting an erroneous:

  "Makefile:XYZ: *** mixed implicit and normal rules. Stop."

on a single explicit target. The reason for this appears to be a presumptive parsing for '%' to decide whether there are mixed targets.

More specifically I have (a reduced version):

...
VERSION=0.3.1-devel-`date +%Y%m%d`
DATAEXE=myapp
...
$(DATAEXE)-bundle-$(VERSION).tar.gz: all #...
...

and make 3.82.90 errors out at the single explicit target "$(DATAEXE)-bundle-$(VERSION).tar.gz". When I remove the date specification from VERSION, it all works again as expected (except I don't have my timestamps anymore). The conclusion is that the date's % specifications are wrongfully interpreted as make's at the parse time as if "containing mixed targets". Please provide a fix and/or a workaround. Thanks!

-s

Serguei Mokhov <mokhov>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by mokhov (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-07-06 psmith StatusNone => Not A Bug
        Open/ClosedOpen => Closed

    Back to the top


    Powered by Savane 3.5