Re: [HACKERS] 8.4 TODO item: make src/port support libpq and ecpg directly
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 [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] 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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] 8.4 TODO item: make src/port support libpq and ecpg directly
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
