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

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

From
Tom Lane
Date:
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


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

From
Andrew Dunstan
Date:

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


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

From
Magnus Hagander
Date:
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


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

From
Bruce Momjian
Date:
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@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +