Re: [PATCH] test/ssl: rework the sslfiles Makefile target

From: Jacob Champion <pchampion(at)vmware(dot)com>
To: "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>
Cc: "daniel(at)yesql(dot)se" <daniel(at)yesql(dot)se>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "andrew(at)dunslane(dot)net" <andrew(at)dunslane(dot)net>
Subject: Re: [PATCH] test/ssl: rework the sslfiles Makefile target
Date: 2021-08-13 00:08:16
Message-ID: dc280bda48b3616bc068aba21db20acaaa6fea13.camel@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Isaac Morland 2021-08-13 00:16:09 Re: Default to TIMESTAMP WITH TIME ZONE?
Previous Message Jacob Champion 2021-08-13 00:08:05 Re: [PATCH] test/ssl: rework the sslfiles Makefile target