[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #47995] Parallel double-colon breaks FORCE

From: Joe Crayne
Subject: [bug #47995] Parallel double-colon breaks FORCE
Date: Tue, 24 May 2016 06:04:50 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0


                 Summary: Parallel double-colon breaks FORCE
                 Project: make
            Submitted by: joecrayne
            Submitted on: Tue 24 May 2016 06:04:48 AM GMT
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: None
        Operating System: POSIX-Based
           Fixed Release: None
           Triage Status: None



This issue was reported on the mailing list
<http://lists.gnu.org/archive/html/bug-make/2016-05/msg00041.html> as a
failure when building git in parallel which uses double-colons to make
multiple recipes run.  It was traced to my patch submitted in bug 44742.  Here
is a minimal test case:

        @echo one

all:: joe
        @echo four

joe: FORCE
        touch joe-is-forced


# $ make
# one
# touch joe-is-forced
# four
# $ make -j
# one
# four


Debug messages show that the "joe" target was erroneously pruned by this
apparent optimization:

   /* Prune the dependency graph: if we've already been here on _this_
     pass through the dependency graph, we don't have to go any further.
     We won't reap_children until we start the next pass, so no state
     change is possible below here until then.  */
  if (f->considered == considered)
      /* Check for the case where a target has been tried and failed but
         the diagnostics haven't been issued. If we need the diagnostics
         then we will have to continue. */
      if (!(f->updated && f->update_status > us_none
            && !f->dontcare && f->no_diag))
          DBF (DB_VERBOSE, _("Pruning file '%s'.\n"));
          return f->command_state == cs_finished ? f->update_status :

I believe this is based on an assumption that I've rendered false.  I'm having
trouble understanding how it was true in the first place.

An easy fix would be to elide this optimization in the case of parallel
double-colon builds.

Paul if you understand the issue better, I'd appreciate your thoughts on it.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]