On Mon, Mar 17, 2025 at 4:12 AM Paul Smith <psm...@gnu.org> wrote: > > On Sat, 2025-03-15 at 08:28 -0400, Dmitry Goncharov wrote: > > On Mon, Mar 10, 2025 at 8:12 AM Paul Smith <psm...@gnu.org> 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 think either way you do it it's difficult or impossible to get the other behavior. With the present behavior, I don't see how the build-too-much can be avoided while keeping order-only. With the proposed change, I don't see how to guarantee that a target's order-only dependency is up-to-date without any possibility of that target itself being updated. > 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. I agree this one would probably cause significant headaches if implemented as a simple change, but the idea of some kind of option that would enable changes of this sort seems attractive. Such an option would likely be useful for other cases as well, and would allow Make to continue to develop and make changes in a non-disruptive way. Britton
