bugmake - Bugs: bug #12078, Failure to recognise updated file...


bug #12078: Failure to recognise updated file from pattern rule with multiple targets

Submitter:  None
Submitted:  Mon 21 Feb 2005 04:56:58 PM UTC
Severity:  3 - Normal Item Group:  Bug
Status:  None Privacy:  Public
Assigned to:  psmith Open/Closed:  Open
Component Version:  3.80 Operating System:  Any
Fixed Release:  None Triage Status:  Small Effort
* Mandatory Fields

Add a New Comment Rich Markup

Sun 02 Oct 2022 06:31:28 PM UTC, comment #4: 

I reopened this.  The change for pattern rules caused some unexpected failures so I changed it back, see bug #62098 and bug #63111

I had make warn if it detects these issues and the plan is to re-introduce this change in the next release (e.g. GNU make 4.5 or whatever comes after 4.4), when users have had a chance to update their makefiles.

Paul D. Smith <psmith>
Group administrator
Tue 20 Sep 2022 01:00:51 PM UTC, comment #3: 

This is fixed along with bug #62809

Paul D. Smith <psmith>
Group administrator
Fri 24 Sep 2010 06:29:17 PM UTC, comment #2: 

Hi folks, thanks for all the hard work.

Any chance of this one being fixed any time soon? After all, pattern rules are the only way of telling make about a program that produces two or more output files. This bug means that it is necessary to run make twice or more when lex (say) is present during a build.

I have a build where many targets are built by a single invocation of a custom tool. I haven't really found a nice work around for this bug.

Tue 01 Mar 2005 05:27:07 PM UTC, comment #1: 

Hm.  Ouch.  The problem is that by the time make notices that b.1st needs to be rebuilt, it's already examined a.2nd and a.1st and determined they DIDN'T need to be rebuilt.  So, it never notices that after b.1st, a.2nd is now out of date.

To fix this, make should check ALL of the co-targets for update when it checks the FIRST co-target.

I'm not sure this change will make it into the next release though.

Paul D. Smith <psmith>
Group administrator
Mon 21 Feb 2005 04:56:58 PM UTC, original submission:  

Consider this:

  $ cat Makefile
  1st := a.1st b.1st c.1st
  2nd := ${1st:.1st=.2nd}

  .PHONY: all
  all: ${2nd}

  a.% b.% c.%: # All the *.1st files are created by a single invocation
    touch ${1st}

  ${2nd}: %.2nd: %.1st
    cat $< >$@

  $ make
  touch a.1st b.1st c.1st
  cat a.1st >a.2nd
  cat b.1st >b.2nd
  cat c.1st >c.2nd
  $ make
  make: Nothing to be done for `all'.

Fine. All files are up to date.

  $ rm b.1st
  $ make
  touch a.1st b.1st c.1st
  cat b.1st >b.2nd
  cat c.1st >c.2nd

Urk! a.2nd is out of date with respect to a.1st. We need to run make again.

  $ make
  cat a.1st >a.2nd




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

Attach Files:

Attached Files
file #2603:  Makefile added by None (335B - application/octet-stream - After a sucessful make invocation, things are still not up to date)


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)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-02 psmith StatusFixed None
        Open/ClosedClosed Open
        Fixed Release4.4 None
    2022-09-20 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.4
        Triage StatusNone Small Effort
    2005-02-21 bobbogo Carbon-Copy- Added bobbogo
    2005-02-21 None Attached File- Added Makefile, #2225

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code