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

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.

regards, tom lane

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.
>
>
>
Works for me.

cheers

andrew

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

Added to TODO:

* Create three versions of libpgport to simplify client code

http://archives.postgresql.org/pgsql-hackers/2007-10/msg00154.php

---------------------------------------------------------------------------

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.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +