BTW, I just checked that Windows 32bit installer ships the libintl.h. Did you try if it works for you? Or it requires more headers? Somehow, Windows 64bit installer installer missed it. I'll fix the build script.
Sure. I'll make the changes so that the next available Windows installers include lbintl.h in $Installdir/include. How about the changes with respect to NLS?
On Mon, Jan 6, 2014 at 2:44 PM, Dave Page <dpage@pgadmin.org> wrote:
On Mon, Jan 6, 2014 at 3:32 AM, Craig Ringer <craig@2ndquadrant.com> wrote: > Hi all > > Out of personal interest (in pain and suffering) I was recently looking > into how to compile extensions out-of-tree on Windows using Visual > Studio (i.e. no PGXS). > > It looks like the conventional answer to this is "Do a source build of > PG, compile your ext in-tree in contrib/, and hope the result is binary > compatible with release PostgreSQL builds for Windows". Certainly that's > how I've been doing it to date. > > How about everyone else here? Does anyone actually build and distribute > extensions out of tree at all? > > I'm interested in making the Windows installer distributions a bit more > extension dev friendly. In particular, I'd really like to see EDB's > Windows installers include the libintl.h for the included libintl, since > its omission, combined with Pg being built with ENABLE_NLS, tends to > break things horribly. Users can always undefine ENABLE_NLS, but it's an > unnecessary roadblock.
Sandeep, can you work on fixing this please?
Thanks.
> Are there any objections from -hackers to including 3rd party headers > for libs we expose in our public headers in the binary distribution? > > Other than bundling 3rd party headers, any ideas/suggestions for how we > might make ext building saner on Windows? > > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > >
