Re: Preventing abort() and exit() calls in libpq - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Preventing abort() and exit() calls in libpq
Date
Msg-id 745046.1625163264@sss.pgh.pa.us
Whole thread Raw
In response to Re: Preventing abort() and exit() calls in libpq  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Preventing abort() and exit() calls in libpq  (Jacob Champion <pchampion@vmware.com>)
Re: Preventing abort() and exit() calls in libpq  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 01.07.21 00:41, Jacob Champion wrote:
>> Spitballing -- if you don't like the stamp file, you could add the
>> check to the end of the $(shlib) rule, surrounded by an ifeq check.
>> Then .DELETE_ON_ERROR should take care of the rest, I think.

> Somewhere in the $(shlib) rule would seem most appropriate.  But I don't 
> understand the rest: What ifeq, and why .DELETE_ON_ERROR?

The variant of this I'd been thinking of was

 $(shlib): $(OBJS) | $(SHLIB_PREREQS)
     $(LINK.shared) -o $@ $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK)
+ifneq (,$(SHLIB_EXTRA_ACTION))
+    $(SHLIB_EXTRA_ACTION)
+endif

(and similarly in several other places); then libpq's Makefile
could set SHLIB_EXTRA_ACTION to the desired thing.

The problem then is, what happens when the extra action fails?
Without .DELETE_ON_ERROR, the shlib is still there and the next
make run will think everything's good.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Preventing abort() and exit() calls in libpq
Next
From: Jacob Champion
Date:
Subject: Re: Preventing abort() and exit() calls in libpq