If libintl.h and any headers it in turn includes are bundled, there is no longer an issue with NLS.
That was just a workaround for building exts when Pg's headers tried to refer to nonexistent headers when NLS was enabled.
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 <dp...@pgadmin.org> wrote:On Mon, Jan 6, 2014 at 3:32 AM, Craig Ringer <cr...@2ndquadrant.com> wrote:Sandeep, can you work on fixing this please?
> 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.
> 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
> Sent via pgsql-hackers mailing list (email@example.com)
> To make changes to your subscription:
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company