I wrote:
> On reflection, let's just go with the solution of building libpgport_lib.a
> with the right flags (fPIC + threading) and leave libpgport.a alone.
> That way we don't need a debate about whether there's an efficiency
> cost worth worrying about.
I looked into this and got discouraged after realizing that not only does
libpq pull in and recompile a bundle of src/port/ files, but also from
src/common/, and even some random backend files like encnames.c and
wchar.c. We could possibly apply the same build-a-third-way technique to
src/common/, but we'd still end up with messiness for the encoding files.
Perhaps what this is telling us is that encnames.c and wchar.c ought to be
moved to src/common/.
On top of that, there are also some interactions with the MSVC build
system that I don't especially want to debug or untangle.
In short, this is looking like a whole lot more work than we could
ever hope to save by not having to maintain these file lists anymore.
So I'm not planning to pursue it. If someone else wants to, though,
have at it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
