Visual Studio 2005, C-language function - avoiding hacks?
in [PgSql]
|
Prev: [HACKERS] Visual Studio 2005, C-language function - avoiding hacks?
Next: SQL compatibility reminder: MySQL vs PostgreSQL
From: Magnus Hagander on 9 Mar 2010 03:00 2010/3/9 Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp>: > > Magnus Hagander <magnus(a)hagander.net> wrote: > >> >> The existing mechanism >> >> works (as demonstrated by the fact that the contrib modules work on >> >> Windows). >> > >> > Did we use non-standard tools except msvc in the build framework >> > for core code? And what should I do for an external project? >> >> Yes, we use mingw. > > Hmmm, it means the existing mechanism can only work on limited environments. > Should we make the code to be more portable for standard developers? That would definitely be good. > Third party developer might not build the postgres server, > but they would want to build their extension modules without mingw. Well, the tool for generating the full export of symbols is in the build tree, so perhaps we jus tneed to ship that. But usually you *don't* want that because, well, it's non-standard. And exporting all symbols makes the binary *much* larger (iirc, postgres.exe grows about 40%). It would perhaps be better to encourage (and document) how people create their own .DEF files to export the specific symbols they need. Because AFAIK, that will work if you do that - or do you know of issues with that method? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |