On Tue, 2021-08-10 at 11:26 -0400, Tom Lane wrote: > Yeah, I don't like that change either. It would be one thing if > we had several places in which suppressing .SECONDARY was useful, > but if there's only one then it seems better to design around it.
Maybe. The current Makefile already tried to design around it, with `rm`s inserted various places. That strategy won't work for the CA state, and my personal interest in trying to manually replicate built- in Make features is... low. > As a concrete example of why this might be a bad idea, how sure > are you that noplace in Makefile.global depends on that behavior? I was hoping that, by scoping the change to only a single Makefile with the clean_intermediates flag, I could simplify that question to "does any place in that one Makefile rely on an affected rule from Makefile.global?" And the answer to that appears to be "no" at the moment, because that Makefile doesn't really need the globals for anything but the prove_ macros. (Things would get hairier if someone included the SSL Makefile somewhere else, but I don't see anyone doing that now and I don't know why someone would.) But -- if I do spend the time to answer your broader question, does it actually help my case? Someone could always add more stuff to Makefile.global. It sounds like the actual fear is that we don't understand what might be interacting with a very broad global target, and that fear is too great to try a scoped change, in a niche Makefile, early in a release cycle, to improve a development issue multiple committers have now complained about. If _that's_ the case, then our build system is holding all of us hostage. Which is frustrating to me. Should I shift focus to help with that, first? --Jacob
