Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Well, maybe the right answer is to take a step back and figure out what
pg_config.h.win32's excuse for living is at all.
Oops, the file is only used by MSVC/BCC, not by MinGW. Sorry for the
mistake about that.
Well, I'm still wondering why it is an input for MSVC. If we have a
configure substitute for MSVC, why isn't it working off pg_config.h.in?
The original idea of pg_config.h.win32 was to support the pre-8.0
method for building native libpq.dll. I'd like to see us obsolete that
method altogether and get rid of pg_config.h.win32.
That makes sense - I'll look at that after I have cleaned up the current
stuff.
However, all the values are hardcoded, so nothing in it should relate to
settings that come from configure, I believe. These should be dealt with
in src/tools/msvc/Solution.pm (mostly in GenerateFiles() ).
FYI, I'm about to commit changes moving XLOG_BLCKSZ and XLOG_SEG_SIZE
into the domain of configurable stuff, too.
So I gathered. I'll pick those up as part of the fixes I'm currently coding.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
