Re: order-only prerequisites themselves get rebuilt when not needed

The patch attached to the savannah issue Dmitry provided below does
include a doc change.  I haven't reviewed it yet.

Basically the current behavior is:

To build target A:
- First try to build all prerequisites
- Compare the modification time of all NON-ORDER-ONLY prerequisites
- If any NON-ORDER-ONLY prerequisite is newer than A:
  - Run the recipe to build A

The proposed behavior is (as I understand it):

To build target A:
- First try to build all NON-ORDER-ONLY prerequisites
- Compare the modification time of all NON-ORDER-ONLY prerequisites
- If any NON-ORDER-ONLY prerequisite is newer than A:
  - Try to build all ORDER-ONLY prerequisites
  - Run the recipe to build A

The big difference is that if A doesn't need to be rebuilt, then order-
only prerequisites are not even considered.


On Mon, 2025-03-17 at 14:02 +0000, Cook, Malcolm wrote:
> Hi, as someone who uses order only prerequisites frequently, I would
> appreciate at restatement of what the proposed change to behavior is
> so I can advise whether I expect my use cases to be affected.
> 
> Perhaps in addition to a code patch  a proposed documentation patch
> could help other lurkers get up to speed with the proposal....???
> 
> 
> 
> From: [email protected]
> Sent: Monday, March 17, 2025 7:10:06 AM
> To: [email protected] <[email protected]>
> Subject: Re: order-only prerequisites themselves get rebuilt when not
> needed
>  
> On Sat, 2025-03-15 at 08:28 -0400, Dmitry Goncharov wrote:
> > On Mon, Mar 10, 2025 at 8:12 AM Paul Smith <[email protected]> wrote:
> > > 
> > > On Sat, 2025-03-08 at 11:34 -0900, Britton Kerin wrote:
> > > > What confuses me is that since the explicitly requested foo
> > > > exists and isn't out of date with respect to any non-order-only
> > > > prereqs (in the example it doesn't have any) and therefore
> > > > isn't
> > > > getting rebuilt, I wouldn't expect there to be any need to
> > > > rebuild it's order-only prereqs either.
> > > 
> > > That's certainly a reasonable way for it to work, but that's not
> > > how it works.
> > 
> > Can we change how it works?
> > i attached a patch here
> > https://savannah.gnu.org/bugs/index.php?66915.
> 
> The question we have think carefully about is what sort of backward-
> compatibility issues, if any, we could introduce. Are there
> situations where people are relying on the current behavior?
> 
> Secondly, we should consider which behavior is easier to work around.
> If there is a reasonable workaround to one choice but not a good way
> to obtain the other behavior, we should choose the harder to obtain
> behavior.
> 
> I'm not really convinced that this need rises to the level of "keep
> both behaviors with some new syntax or option to choose between them"
> so I would prefer not to go that way unless it's proven necessary.