Tom Lane escribió:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On 6 February 2013 14:38, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> >> Yeah, I am doing this right now and the "shared" name doesn't seem so
> >> good. "libpgframework" sounds decent. So since libpgport comes from
> >> src/port, are we okay with src/framework and src/include/framework?
>
> > "common" ?
>
> > src/backend/common
> > src/include/common
>
> To me the term "framework" carries a lot of baggage that doesn't fit
> this usage. "common" seems better.
Okay, here's an attempt at doing it that way. Notably this creates
libpgcommon, a static library, to be used by both frontend and backend.
There's only a frontend file now (fe_memutils.c); the backend side of it
is empty. I verified that the backend makefile rules work, but there's
no attempt to link it into the backend. libpgcommon piggybacks on
libpgport: for instance there is no separate submake-pgcommon rule on
which to depend, or LDFLAGS additions and the like, I just appended it
all to existing pgport rules. Duplicating it would be much more verbose
and pointless; if we ever need to distinguish these two libs, that can
easily be done.
Some existing pg_malloc() implementations tried to do something other
than exit(EXIT_FAILURE); pg_upgrade did pg_log(FATAL) for instance. But
I don't think there is much point in that, so I've just made them all
use fprintf(stderr); exit(EXIT_FAILURE); This is the same approach
Zoltan ended up with in his patch.
MSVC is known broken (I didn't touch Andres' hunk of that. I will look
into that later.)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
