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