Re: 8.4 TODO item: make src/port support libpq and ecpg directly

On Thu, Oct 04, 2007 at 05:33:43PM -0400, Tom Lane wrote:
> This business with having libpq and ecpg pull in src/port modules
> manually is getting unmaintainable. I wonder whether we could persuade
> src/port to generate three versions of libpgport.a --- backend,
> frontend, and frontend-shlib-ready --- and then just -l the appropriate
> one in libpq and ecpg. This'd waste a few cycles building modules that
> would never be used, but on the other hand we'd buy some of that back
> by not building the same object files three or four times.

With so few and small files, I really don't think we need to consider the
effects on build time. It's going to be "fast enough" either way. Going
with the most maintainable way is much more important.

If it actually put the code in the binaries that'd be worse, but the linker
should strip that out, no? Or is that different on 'nix thatn win32?
Because if it does, why do you need a separate one for
frontend-shlib-ready?

FWIW, the MSVC port already does this. The only downside I've seen is that
unless you define proper dependencies libpq won't build without a manual
build of libpgport first. But with proper dependenceis set, that's not an
issue.

//Magnus