From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: __pg_log_level in anonynous enum should be initialized? (Was: pgsql: Change SHA2 implementation based on OpenSSL to use EVP digest ro) |
Date: | 2020-09-30 05:50:25 |
Message-ID: | 20200930055025.GA1996@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Tue, Sep 29, 2020 at 09:29:18AM -0400, Tom Lane wrote:
> Hm, it doesn't seem like "OBJS_PGCOMMON" conveys much. I think
> OBJS_FRONTEND ought to be the set of files built for frontend
> application use (i.e., libpgcommon.a), so we need a new name
> for what will go into libpgcommon_shlib.a. Maybe OBJS_SHLIB,
> or to be even more explicit, OBJS_FRONTEND_SHLIB.
OBJS_SHLIB is already used to list the _shlib.o objects compiled with
libpgcommon_shlib.a, which is why I switched OBJS_FRONTEND to
OBJS_PGCOMMON, and an object cannot reference itself so we either need
two variables for the shlib list, or we could just do something like
that:
OBJS_FRONTEND = \
$(OBJS_COMMON) \
fe_memutils.o \
restricted_token.o \
sprompt.o
OBJS_SHLIB = $(OBJS_FRONTEND:%.o=%_shlib.o)
OBJS_FRONTEND += logging.o
However I would prefer the style of the attached.
> As for the comment, maybe "logging.c is excluded from OBJS_SHLIB
> as a matter of policy, because it is not appropriate for general
> purpose libraries such as libpq to report errors directly."
WFM. Thanks!
--
Michael
Attachment | Content-Type | Size |
---|---|---|
common-shlib-split-v2.patch | text/x-diff | 998 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2020-09-30 05:59:58 | pgsql: Fix XML id to match GUC name |
Previous Message | David Rowley | 2020-09-30 00:05:42 | pgsql: Doc: Improve clarity on partitioned table limitations |
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2020-09-30 05:58:44 | Re: Parallel INSERT (INTO ... SELECT ...) |
Previous Message | Keisuke Kuroda | 2020-09-30 05:39:03 | Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables |